Skip to content

Mocha Tests

Mocha Tests are used to test JavaScript code. They run in Node and can work in the following workspace types:

  • Node
  • Babelnode
  • MongoDB
  • Project (avoid when possible)
  • JavaScript (deprecated)
  • Static (deprecated)
  • Default (depcrecated)

Test Structure


Folder Structure

Mocha tests execute a test.js file located in a /test folder in a learner's workspace. Make sure that there is an empty /test folder in the workspace. With every code submit on a Mocha test checkpoint, the applicable test file will be copied into this folder and executed in the context of the workspace.


Our Mocha test runner treats any output to stdout as error test and causes test failures. To avoid this, replace console.log() with a no-op function at the top of your file).

console.log = () => {};

Test File Structure

Mocha tests use a describe/it block structure:

// Replace console.log
console.log = () => {};
// Import an assertion library
const { expect } = require('chai');

// Describe the context
describe('<object, class, or function name>', () => {
  // Individually assert behaviors
  it('<demonstrates the expected behavior>', () => {
    // Run assertions
    expect(anActualValue, '<error message>').to.equal(anExpectedValue);

The Mocha docs generally advise against using arrow functions, but it's generally fine unless you really to access Mocha's this (for setting a timeout, for example). In the vast majority of cases, arrow functions are just fine.

Unlike unit testing, stick to a single describe/it block when writing LE tests. If there are multiple blocks, multiple error messages will be shown to learners, which can be confusing.

Available Test Helpers

Additional JavaScript packages are available to learners in the Learning Environment, based on this package.json file. In particular, the following packages are helpful for testing:

Package Version Use Case
chai ^4.1.2 Many helpful general assertions
enzyme 2.3.0 React testing
jsdom 9.12.0 Building pure-JS representations of the DOM based on learner code
rewire 2.5.1 Patch in learner code files to access local, not exported variables
sinon 1.10.3 Building mocks & stubs of functions
sinon-chai 2.8.0 Chai extension for sinon asertions
structured CC version Run tests based on parsing code structure rather than execution or behavior
supertest 3.0.0 API endpoint testing

Tests execute in Node v7.10.1, so any Node 7 APIs are available as well, such as fs, path, etc.

Example Tests

Testing Variables in Learner Code

This test checks that a learner has declared a top-level variable myName with the given value "Codecademy".

console.log = () => {};
const { expect } = require('chai');
const rewire = require('rewire');

// describe/it strings are not necessary because we use custom error messages below
describe('', function() {
  it('', function() {
    let appModule;
    try {
      // Because of the test.js file context, ths path must be relative
      appModule = rewire('../main.js');
    } catch (e) {
      // If this try/catch fails, it means the rewire could not complete and there is a syntax error.
      expect(true, 'Try checking your code again. You likely have a syntax error.').to.equal(false);

    let leanerVariable;
    let learnerVariableName = 'a';
    try {
      leanerVariable = appModule.__get__(learnerVariableName);
    } catch (e) {
      // If this try/catch fails, it means that the given variable did not exist
      expect(true, `Declare a \`${learnerVariableName}\` variable in your code.`).to.equal(false);

    // These are just two possible assertion examples, you can use the whole Chai expect API
    expect(leanerVariable, `Make sure that the \`${learnerVariableName}\` variable is a string.`)'string');
    expect(leanerVariable, `Make sure that your \`${learnerVariableName}\` has a value exactly equal to \`'Codecademy'\`.`).to.equal('Codecademy');

Other Guidelines

  • Actual code (real variable names, language syntax, etc. ) in feedback messages should be code-ticked (`)
  • Mocha tests should follow Test standards.