1 2 3 4 next »

1. Introduction
2. Writing and structuring tests
3. Inits, asserts and async tests
4. Configuring, browsers and conclusion

Unit testing with Node.js

by Golo Roden

Consistent unit testing is a basic quality requirement in modern software development and Node.js is very much a modern software platform. With Mocha, TJ Holowaychuk has created a framework for writing and executing Node.js unit tests; its biggest strength lies in the testing of asynchronous code and it can also be executed in a web browser.

In a sense, Node.js already contains all the tools that are required for writing unit tests by default. While the first two phases of the AAA pattern, Act and Arrange, don't impose any special requirements, the third, Assert, often requires a module that provides a function of the same name.

In Node.js, this functionality is available via the assert module. Although it appears to be highly useful at first glance, the module itself without any additional tools is actually almost unsuitable for everyday use. It doesn't offer much more than equality and non-equality assertion tests for two values and tests for finding exceptions. What's more, another tool for executing unit tests is missing completely from Node.js: there is no test runner.

This is where the Mocha module comes into play. It is a simple yet powerful framework for Node.js and for web browsers, and its particular strength lies in testing asynchronous code.

Installing and configuring Mocha

Mocha is installed in Node.js in the normal way via the Node Package Manager (npm). It is usually installed globally, because individual, user-specific instances tend to be unnecessary:

$ sudo npm install -g mocha

Once installed, Mocha can be called from within any application using the command of the same name:

$ mocha

It is worth noting that without any explicitly stated files to test, Mocha will look for a test directory within the current directory and will execute any files in this directory one after the other. It won't consider any subdirectories that may be included, though, and will only focus on the directory's top level.

Therefore, it makes sense to add a relevant test directory to every application. Mocha must always be called from within the test directory's parent directory. When called from a different directory, Mocha's default response is the initially rather confusing error message that it can't find the test.js file.

Of course, the instruction to call Mocha can also be added to the package.json file, which will allow tests to be executed via the alternative

$ npm test

command. To do so, the following code block must be added to the file:

{
  [...],
  'scripts': {
    'test': 'mocha'
  },
  [...]
}

Mocha also offers a range of command line parameters that can be listed by calling --help. To avoid having to manually enter them every time, the parameters can be stored as default values in a file called mocha.opts in the test directory. Each parameter must be listed on a separate line.

Should the parameters that are defined in this file be in conflict with any manually submitted parameters, the latter will be given priority. Mocha's most important parameters are discussed later in this article

Next page: Writing and structuring tests

1 2 3 4 next »