With the installation of Node, the Node Package Manager (NPM) is also installed. NPM is actually the utility that we will use for our normal development cycle.

NPM allows you to install libraries, manage the dependencies of your projects, and define a set of commands to build your code.

To start, just create a new folder for your project and initialize it from there:

$ me@~> mkdir validator
$ me@~> cd validator
$ me@~/validator> npm init

The last command, npm init, will invoke NPM to generate package.json inside the current directory; during the process, it will ask you some questions. Most of them are self-explanatory, but if you do not know what to answer just press ENTER. Do not worry; you will be able to edit the package.json file later. This is my package.json file:

{
  "name": "validator",
  "version": "0.1.0",
  "description": "A validation service for Weird LTD.",
  "main&quot...

Mocha is a modern test runner that can be executed from Node as well as inside a browser. As we saw earlier, our main approach is to use Node. In this book, I am using Mocha Version 1.20.1, but any 1.x version should be OK.

We have already installed Mocha using NPM, so we can run it with the following command:

$ me@~/validator> ./node_modules/.bin/mocha -u bdd -R spec -t 500 --recursive

It fails because we do not have any test yet; we will fix it later. I will explain the exact meaning of these parameters in a moment. For now, note that, to execute Mocha, we need to find out where NPM has installed the executable of the tool. A package can be a simple library, or it can also contain an executable command-line tool, as is the case with Mocha. NPM always will install this executable in the node_modules/.bin/ folder; hence, we need to execute ./node_modules/.bin/mocha in order to invoke Mocha.

This would not have been necessary if we had installed Mocha as a global package...

We have already installed chai as a dependency of our project, but we have not yet used it. Specifically, I am using version 1.9.1, but any 1.x version should be OK.

Until now, we have been using the standard assert package to create our assertions. The assert package is not bad, but it is limited to a few assertions. It is not extensible, and some people found it a bit difficult to read. I personally always find myself wondering, "Is the first parameter the actual value or the expected one?" Actually, the first parameter is the actual value, and the second one is the expected value. This is important because the report message depends on distinguishing the actual value from the expected one. Let's change the code of our test to use chai:

var chai = require('chai'),
    expect = chai.expect,
    validator = require('../lib/validator');

describe('A Validator', function() {
  it('will return error.nonpositive...

Now that we have a basic knowledge of Chai, we can continue with our coding. The code we already have in place is clearly not correct, so we need to add another test that forces us to make the code right.

Currently, we are implementing the rule about errors for nonpositive numbers, so we should finish it before continuing. Which test could we add to make our implementation fail? We can try testing the validator with valid numbers. Let's see the result:

describe('A Validator', function() {
  it('will return no errors for valid numbers', function() {
    expect(validator(3)).to.be.empty;
  });

  it('will return error.nonpositive for not strictly positive numbers', function() {
    expect(validator(0)).to.be.deep.equal(['error.nonpositive']);
  });
});

Note that we have added a new test for valid numbers that is failing. So now we fix it in a very simple way in lib/validator.js:

module.exports = function (n) {
  if(n === 0)
    return...

A few weeks after going to production, our validator is a complete success but it also happens that potential new customers would like to have different sets of validation rules. Fortunately, our validator is configurable, but we somehow need to specify a different configuration for each customer.

The act of configuring a different set of rules for each customer is clearly another operation of the system and, hence, a different feature, so we are not really interested in testing it in the validator tests. We would like to isolate the tests about the validator feature and the configuration feature. To do so, we need to create an interface in a way that allows the validator to ask for the correct set of rules for the configuration. Then we can create a test double for such an interface in our tests. The test double will impersonate the real configuration and allow us to isolate our tests.

When creating these test doubles we need to design the shape of the interfaces...