Mocha.js, the JavaScript test framework: A tutorial

No matter what kind of app you’re building, you should always test it before deployment.

There are myriad test frameworks available, including Jest, Jasmine, QUnit, Karma, Cypress, and several others. One of the most popular test frameworks for JavaScript is Mocha.js.

In this comprehensive tutorial, we’ll demonstrate how to test a Node.js app with Mocha.js, including writing your own test suites and running Mocha tests in the browser.

We’ll cover the following in detail:

• What is Mocha.js?
• What is Mocha.js used for?
• Is Mocha.js a BDD tool?
• Running a Mocha test in Node.js
• Writing tests with Mocha.js
• Using Mocha.js and Chai.js
• Using the Mocha.js BDD interface
• Writing a test suite with Mocha.js
• Testing asynchronous code with Mocha.js
• Using test hooks with Mocha.js
• What is Mocha describe()?
• Controlling Mocha.js tests
• Mocha.js CLI options
• Mocha.js in the browser

What is Mocha.js?

Mocha.js is an open-source JavaScript test framework that runs on Node.js and in the browser. It’s designed for testing both synchronous and asynchronous code with a very simple interface.

Mocha.js runs tests serially to deliver flexible and accurate reporting while mapping uncaught exceptions to their corresponding test cases.

What is Mocha.js used for?

Mocha.js provides functions that execute in a specific order and logs the results in the terminal window. It also cleans the state of the software being tested to ensure that test cases run independently of each other.

While it can be used with most assertion libraries, Mocha.js is commonly used with Chai, a popular assertion library for Node.js and the browser.

Is Mocha.js a BDD tool?

Mocha.js provides a variety of interfaces for defining test suites, hooks, and individual tests, including TSS, Exports, QUnit, and Require. The default interface is BDD.

Behavior-driven development (BDD) aims to help developers build software that is predictable, resilient to changes, and not error-prone. It evolved from test-driven development (TDD), which requires you to:

We made a custom demo for .
No really. Click here to check it out.

Click here to see the full demo with network requests

1. Write tests for the required software functionality
2. Run the tests for the software functionality
3. Implement the software functionality
4. Fix bugs and refactor until all tests pass
5. Repeat the cycle for any new functionality

The main difference between TDD and BDD is that BDD calls for writing test cases in a shared language to simplify communication between technical and nontechnical stakeholders, such as developers, QA teams, and business leaders.

Running a Mocha test in Node.js

First, you’ll need to install Mocha.js either globally on your local machine or as a dependency for your project.

Here’s how to install globally it using npm:

npm i --global mocha

To install Mocha as a development dependency for your project:

npm i --save-dev mocha

Installing Mocha.js globally on your local machine makes the mocha CLI binary available for use in your command-line terminal. You can run tests with Mocha on your terminal.

mocha

If you only installed Mocha.js as a development dependency for your project, you can access the mocha binary from the node_modules directory of your project.

./node_modules/mocha/bin/mocha

To complete your Mocha.js setup, you will have to write a unit test for a very simple functionality and configure a script to run the test using Mocha.

Mocha.js automatically looks for tests inside the test directory of your project. Go ahead and create this directory in your project root.

mkdir test

Next, modify the “test” script in your package.json to run tests using Mocha. Here’s what it should look like:

/* package.json */

{
  "scripts": {
    "test": "mocha"
  }
}

With this setup, you can simply run the tests in your project using this simple command:

npm test

Writing tests with Mocha.js

At the moment, we have everything set up for running your tests with Mocha, but we don’t have any tests to run yet. The next step is to start writing tests for the desired functionalities of your software.

Using Mocha.js and Chai.js

Writing tests often requires using an assertion library. Mocha.js does not discriminate, regardless of which assertion library you choose to use.

If you’re using Mocha in a Node.js environment, you can use the built-in assert module as your assertion library. However, there are more extensive assertion libraries you can use, such as Chai, Expect.js, Should.js, etc.

For all the tests in this guide, we’ll use Chai.js as the assertion library.

Install Chai.s as a dependency for your project.

npm i --save-dev chai

Chai provides the following assertion styles:

Assert style:

var assert = require('chai').assert;
var numbers = [1, 2, 3, 4, 5];

assert.isArray(numbers, 'is array of numbers');
assert.include(numbers, 2, 'array contains 2');
assert.lengthOf(numbers, 5, 'array contains 5 numbers');

Expect style:

var expect = require('chai').expect;
var numbers = [1, 2, 3, 4, 5];

expect(numbers).to.be.an('array').that.includes(2);
expect(numbers).to.have.lengthOf(5);

Should style:

var should = require('chai').should();
var numbers = [1, 2, 3, 4, 5];

numbers.should.be.an('array').that.includes(2);
numbers.should.have.lengthOf(5);

You can learn more about the assertions and assertion styles Chai provides in the official Chai documentation.

Using the Mocha.js BDD interface

Here is what a test suite defined using the BDD interface looks like:

// begin a test suite of one or more tests
describe('#sum()', function() {

  // add a test hook
  beforeEach(function() {
    // ...some logic before each test is run
  })
  
  // test a functionality
  it('should add numbers', function() {
    // add an assertion
    expect(sum(1, 2, 3, 4, 5)).to.equal(15);
  })
  
  // ...some more tests
  
})

Writing a test suite with Mocha.js

It’s time for you to write your first test suite and run the tests with Mocha. To start, you must implement a sum() function that:

• Can accept any number of arguments
• Requires all arguments to be numbers and throws an error if any is not a number
• Computes and returns the sum of its arguments provided all are numbers
• Returns 0 if no argument is passed

First, define the test suite with tests for the required functionalities.

Create a new sum.js file in the test directory of your project and add the following code snippet to it.

/* test/sum.js */

var sum = require('../sum.js');
var expect = require('chai').expect;

describe('#sum()', function() {

  context('without arguments', function() {
    it('should return 0', function() {
      expect(sum()).to.equal(0)
    })
  })
  
  context('with number arguments', function() {
    it('should return sum of arguments', function() {
      expect(sum(1, 2, 3, 4, 5)).to.equal(15)
    })
    
    it('should return argument when only one argument is passed', function() {
      expect(sum(5)).to.equal(5)
    })
  })
  
  context('with non-number arguments', function() {
    it('should throw error', function() {
      expect(function() {
        sum(1, 2, '3', [4], 5)
      }).to.throw(TypeError, 'sum() expects only numbers.')
    })
  })
  
})

Notice that the sum module was required in the test file though it has not been created yet. Also notice that the sum() call is wrapped in a function to test that an error is thrown when non-number arguments are passed. This is a requirement of the .throw() assertion as specified in the Chai assertions documentation.

Next, go ahead and implement the functionality for the sum() function as a module export, run the tests, and ensure that all the tests pass.

Create a new sum.js file in the root directory of your project containing the following code snippet.

/* sum.js */

module.exports = function() {

  // Convert arguments object to an array
  var args = Array.prototype.slice.call(arguments);
  
  // Throw error if arguments contain non-finite number values
  if (!args.every(Number.isFinite)) {
    throw new TypeError('sum() expects only numbers.')
  }
  
  // Return the sum of the arguments
  return args.reduce(function(a, b) {
    return a + b
  }, 0);
  
}

You can run the tests now on your terminal by running the “test” script defined earlier:

npm test

You should get an output that looks like this:

Testing asynchronous code with Mocha.js

The tests you have written so far are for functionalities involving code that is executed synchronously. However, most Node.js applications require a lot of asynchronous code. Mocha.js also makes it easy to test asynchronous code with a very similar syntax.

You can use any of the following to test asynchronous code with Mocha.js.

1. A callback function
2. Promises (for environments that support for promises)
3. async/await (for environments that support async functions)

Let’s look at each of these methods in depth.

1. Callback function

The function passed as second argument to it() can be passed an optional callback function as its first argument. When this callback function is passed, Mocha.js knows that the test is for asynchronous functionality. Conventionally, the callback function is named done, but you are at liberty to use any identifier you choose.

it('test expectation', function(done) {
// test asynchronous code
// call done() to terminate test and proceed to the next test
}

There are a few things to note about the done() callback:

1. It must be called for Mocha.js to terminate the test and proceed to the next test; otherwise, the test keeps running until the timeout reaches
2. It should not be called more than once within an it() function block. Calling it multiple times will throw an error
3. It is a Node-style callback, hence it can take an Error instance (err) as its first argument
4. Calling the done() callback with an Error instance causes the test to fail with the given error

Before you proceed, here is a simple module that exports an asynchronous md5() function for computing the MD5 hash of a string.

Create a new md5.js file in the root directory of your project and add the following content to it.

/* md5.js */

var crypto = require('crypto');

module.exports = function(string, callback) {
  var withCallback = typeof callback === 'function';
  
  try {
  
    var hash = crypto.createHash('md5')
      .update(string)
      .digest('hex');
      
    withCallback && callback(null, hash);
    
  } catch (e) {
    if (withCallback) callback(e);
    else throw e;
  }
}

The following code snippet contains a simple test for this asynchronous function using a callback function.

Create a new md5.js file in the test directory of your project and add the following.

/* test/md5.js */

var md5 = require('../md5');
var expect = require('chai').expect;

describe('#md5()', function() {

  context('with string argument', function() {
    it('should compute MD5 hash', function(done) {
    
      md5('Glad Chinda', function(err, hash) {
        // call the done() callback with the error if any
        // to terminate the test with an error
        if (err) return done(err);
        
        // add some assertions
        expect(hash)
          .to.be.a('string')
          .that.matches(/^[a-f0-9]{32}$/)
          .and.equal('877dbb93f50eb8a89012e15bd37ee7e4');
          
        // finally call the done() callback
        // to terminate the test
        done();
      })
      
    })
  })
  
  context('with non-string argument', function() {
    it('should throw an error', function(done) {
    
      md5(12345, function(err, hash) {
        // call the done() callback with the error if any
        // to terminate the test
        if (err) {
        
          // add an assertion to check the error
          expect(function() { throw err })
            .to.throw(TypeError, 'The “data” argument must be of type string or an instance of Buffer, TypedArray, or DataView');
            
          // finally call the done() callback
          // to terminate the test and return
          return done();
          
        }
        
        // call the done() callback
        // to terminate the test
        done();
      })
      
    })
  })
  
})

If you run the tests now on your terminal, you’ll get an output that looks like this:

2. Promises

If you’re developing in an environment with support for promises, it’s likely that most of the asynchronous operations will be based on promises. Mocha.js also makes it possible for you to test asynchronous code that uses promises.

Whenever you return a promise from the function passed to it(), Mocha knows that the functionality to be tested is asynchronous, so it waits for the promise to be fulfilled before proceeding to the next test.

From Mocha.js v3.0.0 and newer, calling the done() callback when a promise is returned results in an exception, since this is not allowed. However, in older versions of Mocha, the call is ignored.

To test asynchronous code that uses promises, you will create another version of the md5 module that is based on promises.

Create a new promise-md5.js file in the root directory of your project with the following content.

/* promise-md5.js */

const md5 = require('./md5');

module.exports = (string) => new Promise(
  (resolve, reject) => {
    md5(string, (err, hash) => {
      return err ? reject(err) : resolve(hash)
    })
  }
)

The following code snippet contains a simple test suite for the promise-md5 module. Create a new promise-md5.js file in the test directory of your project and add the following.

/* test/promise-md5.js */

var promiseMd5 = require('../promise-md5');
var expect = require('chai').expect;

describe('#promiseMd5()', function() {

  context('with string argument', function() {
    it('should compute MD5 hash', function() {
    
      return promiseMd5('Glad Chinda')
        .then(function(hash) {
          // add some assertions
          expect(hash)
            .to.be.a('string')
            .that.matches(/^[a-f0-9]{32}$/)
            .and.equal('877dbb93f50eb8a89012e15bd37ee7e4');
        })
        
    })
  })
  
  context('with non-string argument', function() {
    it('should throw an error', function() {
    
      return promiseMd5(12345)
        .catch(function(err) {
          // add an assertion to check the error
          expect(function() { throw err })
            .to.throw(TypeError, 'The “data” argument must be of type string or an instance of Buffer, TypedArray, or DataView');
        })
        
    })
  })
  
})

Now go ahead and run the test with this slightly modified test command:

npm test -- -f promiseMd5

This command uses -— to pipe the command options and arguments to the underlying mocha CLI binary. The -f flag instructs Mocha.js to run only tests that contain the given string, which in this case is promiseMd5.

Here is what the output should look like:

3. async/await

For environments that support the more recent async/await syntax, Mocha.js also supports passing async functions as the second argument to it().

The previous promise-md5.js tests can be rewritten as follows.

/* test/promise-md5.js */

var promiseMd5 = require('../promise-md5');
var expect = require('chai').expect;

describe('#promiseMd5()', function() {

  context('with string argument', function() {
    it('should compute MD5 hash', async function() {
    
      // use await to wait until the promise is fulfilled
      var hash = await promiseMd5('Glad Chinda');
      
      // add some assertions
      expect(hash)
        .to.be.a('string')
        .that.matches(/^[a-f0-9]{32}$/)
        .and.equal('877dbb93f50eb8a89012e15bd37ee7e4');
    })
    
  })
  
  context('with non-string argument', function() {
    it('should throw an error', async function() {
    
      await promiseMd5(12345).catch(function(err) {
        // add an assertion to check the error
        expect(function() { throw err })
          .to.throw(TypeError, 'The “data” argument must be of type string or an instance of Buffer, TypedArray, or DataView');
       })
       
    })
  })
  
})

Using test hooks with Mocha.js

Mocha.js makes provision for creating test hooks. Hooks are basically logic that have been configured to run before or after tests. They are useful for setting up preconditions for tests or cleaning up resources after tests.

With the default BDD interface, Mocha.js provides four hooks:

1. before()  runs once before the first test case in the block
2. beforeEach()  runs before each test case
3. afterEach()  runs after each test case
4. after()  runs once after the last test case in the block

Depending on the hooks that apply to a given test suite, the hooks are run together with the tests in the suite in a definite sequence.

before() -> beforeEach() -> test() -> afterEach() -> after()

Creating hooks

Each hook basically takes a callback function as an argument. The callback function contains logic to be executed when the hook is triggered. The logic can be either synchronous or asynchronous just as it is with regular test cases.

describe('some module', function() {

  beforeEach(function() {
    // some logic to run before each test
    // logic can be sync or async
  })
  
})

Hooks can also take an optional description as the first argument, which makes it easier to track errors. However, if a named function is passed as an argument to a hook, the name of the function is used as a description if no explicit description was passed.

describe('some module', function() {

  // HOOK WITH NAMED FUNCTION
  beforeEach(function createSession() {
    // beforeEach:createSession
  })
  
  // HOOK WITH DESCRIPTION
  beforeEach('create a user session', function() {
    // beforeEach:create a user session
  })
  
})

What is Mocha describe()?

The describe() function is a way to group tests in Mocha.js. You can nest your tests in groups as deep as you deem necessary.

describe() takes two arguments:

1. The name of the test group
2. A callback function

The root suite

Whenever a hook is defined outside a definite describe() block, the hook becomes a root-level hook. Root-level hooks apply to all test files regardless of where they are defined. This is because Mocha implicitly creates a describe() block, called the root suite.

In the following code snippet, the afterEach() hook will be triggered after every test in every file.

var tests = 1;

// Will run after every test in every file
afterEach(function() {
  console.log('Test #' + (tests++));
})

Sometimes, you may want to perform an asynchronous operation before running any of your test suites. Mocha.js allows you to delay the root suite by running the mocha binary with the --delay option.

For your project’s test command, it will look like this:

npm test -- --delay

Running this command instructs Mocha.js to attach a special run() callback function to the global context. Calling the run() function instructs it to run all the test suites that have been described. Hence, run() can be called after the asynchronous operation is completed in order to run the tests.

To see an example, add the following code snippet to any of the test files you created earlier (it must never be inside an it() block).

// Delay running the tests until after 5s
setTimeout(function() {
  run()
}, 5000);

Now run the tests with the following command.

npm test -- --delay

Notice that the tests are delayed for five seconds and then they run. However, if the run() method is never called, the tests will never run.

Here is what the output should look like:

Controlling Mocha.js tests

Whenever a callback function is not passed as second argument to it(), the test case is marked as pending, which indicates that the test is yet to be written. Pending tests are not failed tests and they are included in the test results.

describe('#flattenArray()', function() {
  // a pending test
  it('should flatten array');
})

Including and excluding tests

You can also specify test suites and test cases that should or should not be run. Mocha.js provides two helpful methods: only() and skip(), for controlling exclusive and inclusive behavior of test suites and test cases.

Use the describe.skip() method to prevent the tests in a suite from running and the describe.only() method to ensure that the tests in a suite run.

// Tests in this suite will run
describe.only('#flattenArray()', function() {
  it('should flatten array', function() {});
})

// Tests in this suite will not run
describe('#mergeArray()', function() {
  it('should merge two arrays', function() {});
})

This also applies to test cases using it(). You can skip a test at runtime by calling this.skip() inside the callback function passed to it(). This makes it possible to dynamically skip a test based on some condition.

Calling this.skip() effectively aborts the test. It is considered best practice to avoid executing further instructions after a call to this.skip(). Every test that is skipped at runtime using this.skip() will be marked as a pending test.

describe.only('#flattenArray()', function() {
  // This test will run
  it.only('should flatten array', function() {});
  
  // This test will not run
  it('should recursively flatten array', function() {});
})

describe.only('#mergeArray()', function() {

  // This test is skipped at runtime for production environment
  // In production, it will not run and will be marked as pending
  
  it('should merge two arrays', function() {
    if (process.env.NODE_ENV === 'production') {
      return this.skip();
    }
  });
  
})

You can use .only() and .skip() multiple times to select a set of suites and tests to run. However, you must note the following:

• Nested suites will still be executed
• Hooks will still be executed if present
• Tests will have precedence

Retrying Mocha.js tests

Mocha.js enables you to specify the number of times a failed test can be retried. This is not recommended for unit tests, but it can be useful when writing end-to-end tests (where some external resources may not be available for some reason).

Mocha.js provides a this.retries() function that allows you specify the number of times a failed test can be retried. For each retry, Mocha reruns the beforeEach() and afterEach() hooks but not the before() and after() hooks.

The following code snippet shows a simple example that uses the Cypress test runner to visit a webpage. If the server responds with a status code other than 2xx, possibly because of slow network or bad internet connection, the test is marked as failed.

describe('test medium site', function() {

  // all failed tests in this suite will only be retried 2 times
  this.retries(2);
  
  it('should load medium homepage', function() {
    // can only retry this test 5 times
    this.retries(5);
    
    cy.visit('https://medium.com');
  })
  
})

With this.retries(5), the test is allowed to be retried a maximum of 5 times before it can be marked as failed.

Slow tests with Mocha.js

Mocha.js allows you to define the amount of time that should elapse before tests are considered as being slow. The this.slow() method is available for this purpose. The number passed to this.slow() represents the amount of time in milliseconds.

describe('slow test', function() {

  // Tests will be considered slow after 1 second elapses
  this.slow(1000);
  
  // Completes after the specified 1 second elapses
  it('should be complete in a second', function(done) {
    setTimeout(done, 1500);
  })
  
  // Completes immediately
  it('should be complete instantly', function() {})
  
})

Notice the red (1506ms) indicator used to mark the slow test. The test is considered slow because it took more than the specified 1 second (1000ms) to run completely.

Timeouts

By default, Mocha.js will timeout for any test that takes more than 2 seconds (2000ms) to run completely. When a timeout happens, the test is marked as failed and a timeout error is thrown.

However, Mocha.js provides a this.timeout() method for specifying the amount of time that should elapse before a timeout happens for a given test suite, hook or test case. The number passed to this.timeout() represents the amount of time in milliseconds.

The timeout can be configured differently at different levels (suite, hook and test levels).

describe('some time-consuming operation', function() {

  // set a 5 seconds timeout for this suite
  this.timeout(5000);
  
  before('some long setup', function(done) {
    // set a hook-level timeout
    this.timeout(2500);
    
    setTimeout(done, 2250);
  })
  
  it('should take less than 200ms', function(done) {
    // set a test-level timeout
    this.timeout(200);
    
    setTimeout(done, 150);
  })
  
})

Note that, calling this.timeout() with 0 disables timeout completely.

describe('some time-consuming operation', function() {

  // disable timeout for this suite
  this.timeout(0);
  
  // test that takes a long time to complete
  it('should take a long time', function(done) {
    setTimeout(done, 10000);
  })
  
})

Mocha.js CLI options

So far, you have been exposed to all the tooling that Mocha.js makes available for writing tests. However, there are still lots of utilities you can leverage when using Mocha, several of which are only available to you when using the mocha CLI binary.

To get the list of available options you can apply to mocha, run the following command.

mocha -h

From your project you can use this command instead:

npm test -- -h

Watching Mocha.js test files

The -w, --watch flag instructs Mocha.js to watch for changes in test files and re-run the tests. This is very useful for writing tests while in development.

mocha --watch

Async and bail

The -A, --async-only flag forces all tests to require a callback function or return a promise, thereby behaving asynchronously. Tests that don’t specify a callback function or return a promise will be marked as failed.

mocha --async-only

The -b, --bail flag forces Mocha.js to bail after the first test failure.

mocha --bail

Handling timeouts and slow tests in Mocha.js

The -t, --timeout <ms> option allows you to set the timeout for your test cases. Mocha.js uses a default of 2 seconds. You can set the timeout by specifying the number of milliseconds or a value with an s suffix to specify the time in seconds.

mocha -t 3000

The above is equivalent to:

mocha --timeout 3s

To disable timeouts entirely, you can use --no-timeouts, which is equivalent to --timeout 0.

mocha --no-timeouts

Mocha also allows you to set the threshold for slow running tests by using the -s, --slow <ms> option. The default threshold is 75ms. As you saw earlier, Mocha.js uses this threshold value to highlight tests that are taking too long to run.

mocha --slow 100

Running matching tests

The -g, --grep <pattern> flag instructs Mocha.js to run tests and test suites that match a particular pattern (regular expression), which is internally converted to a RegExp.

The -f, --fgrep <string> flag, as stated earlier, instructs Mocha.js to run only tests and test suites that contain the specified string.

The following command will run all tests and test suites that contain the string ‘array’.

mocha -f array

Including files and modules

The -r, --require <module> flag allows you to require modules/libraries that you use in your test files such as assertion libraries instead of manually invoking require() in your code. This works for modules like should.js. However, to access the module’s exports, you will have to require the module in your code.

mocha --require should

The --file <file> flag allows you to add one or more files you want to be included first in your test suite. These files may contain some form of setup logic required for your tests. The --file flag can be used multiple times to include multiple files.

Mocha.js interface and reporter

Mocha.js provides several interfaces for writing tests. The default is the BDD interface, which is what is being used throughout this guide. The -u, --ui <name> allows you to specify another interface to use.

mocha --ui exports

The -R, --reporter <name> flag allows you to specify the reporter you prefer for displaying the test results. The default reporter is spec, which is what is being used throughout this guide. Mocha.js also allows you to specify third-party reporters using this flag.

mocha -R list

Mocha.js in the browser

The Mocha test runner can also be used in the browser. Every release of Mocha.js contains builds of ./mocha.css and ./mocha.js for use in the browser. Here is a simple setup to run Mocha tests on the browser.

Set up public files

Create a new public directory in the root of your project. Next, create a new file named index.html in the just created public directory and add the following.

<!-- public/index.html -->

<!doctype html>
<html>
<head>
  <meta charset="utf-8">
  <title>Mocha Tests</title>
  
  <!-- Include Mocha CSS styles -->
  <link href="https://cdn.rawgit.com/mochajs/mocha/2.2.5/mocha.css" rel="stylesheet">
</head>

<body>
  <div id="mocha"></div>
  
  <!-- Add the Chai assertion library -->
  <script src="http://chaijs.com/chai.js"></script>
  
  <!-- Add the Mocha test library -->
  <script src="https://cdn.rawgit.com/mochajs/mocha/2.2.5/mocha.js"></script>
  
  <script>
    // Set chai.expect as a global variable
    var expect = chai.expect;
    
    // Setup Mocha to use the BDD interface
    mocha.setup('bdd');
  </script>
  
  <!-- Import the sum function -->
  <script src="/sum.js"></script>
  
  <!-- Import the tests for the sum function -->
  <script src="/sum.test.js"></script>
  
  <script>
    // Run the tests with Mocha
    mocha.run();
  </script>
    
</body>
</html>

Here, notice that the static CSS and JS files for Mocha and the Chai assertion library have been imported into the page. The element serves as the mount point for displaying the test results.

In setting up Chai, chai.expect is mapped to a global variable named expect so that it can be used in the test scripts for making assertions.

Mocha.js is set up to use the BDD interface by calling mocha.setup(‘bdd’). The tests are run using the mocha.run() method.

Next, create a new sum.js file inside the public directory you created earlier and add the following content to it:

/* public/sum.js */

function sum() {
  // Convert arguments object to array
  var args = Array.prototype.slice.call(arguments);
  
  // Throw error if arguments contain non-finite number values
  if (!args.every(Number.isFinite)) {
    throw new TypeError('sum() expects only numbers.')
  }
  
  // Return the sum of the arguments
  return args.reduce(function(a, b) {
    return a + b
  }, 0);
}

Next, create a new sum.test.js file in the public directory with the following.

/* public/sum.test.js */

describe('#sum()', function() {
  context('without arguments', function() {
  
    it('should return 0', function() {
      expect(sum()).to.equal(0)
    })
    
  })
  
  context('with number arguments', function() {
  
    it('should return sum of arguments', function() {
      expect(sum(1, 2, 3, 4, 5)).to.equal(15)
    })
    
    it('should return argument when only one argument is passed', function() {
      expect(sum(5)).to.equal(5)
    })
    
  })
  
  context('with non-number arguments', function() {
  
    it('should throw error', function() {
      expect(function() {
        sum(1, 2, '3', [4], 5)
      }).to.throw(TypeError, 'sum() expects only numbers.')
    })
    
  })
})

Set up a simple server

Next, you can optionally set up a simple server to serve the public files. For this demo, we’ll use live-server. Go ahead and install it as a dependency for your project as follows:

npm install --save-dev live-server

Modify the “scripts” section of your package.json file to include a script for serving the public files and running the Mocha tests in the browser. It should look like this:

/* package.json */

{
  "scripts": {
    "test": "mocha",
    "test:browser": "live-server --port=9000 --mount=/:public"
  }
}

Here, we’ve added a “test:browser” script to start the live server on port 9000 and serve the files from the public directory.

Finally, run the new script.

npm run test:browser

This should start the server on port 9000 and launch a browser tab for you. The test output on the browser should look like this:

Conclusion

In this guide, we took you through the basics of Mocha.js testing on Node.js and also in the browser. We also demonstrated how to write and run tests for your JavaScript programs.

Although this guide is quite extensive, you can always refer to the Mocha.js documentation for any details not covered by this guide.

200’s only Monitor failed and slow network requests in production

Deploying a Node-based web app or website is the easy part. Making sure your Node instance continues to serve resources to your app is where things get tougher. If you’re interested in ensuring requests to the backend or third party services are successful, try LogRocket. https://logrocket.com/signup/

LogRocket is like a DVR for web and mobile apps, recording literally everything that happens while a user interacts with your app. Instead of guessing why problems happen, you can aggregate and report on problematic network requests to quickly understand the root cause.

LogRocket instruments your app to record baseline performance timings such as page load time, time to first byte, slow network requests, and also logs Redux, NgRx, and Vuex actions/state. Start monitoring for free.