When writing tests for an application, you typically write them in batches that are module specific. These batches are referred to as suites or specs. Each suite typically contains a batch of tests organized in a way that almost mirrors the application itself. With Node, the idea is no different in that each suite of tests we write will be specific to an individual module. You'll require the module you want to test against and write a collection of tests for each part of the module's functionality.

Since you'll have many different test files testing each and every component of your application, you'll want a way to quickly execute all of the tests. This is where the test runner comes in. The test runner that we've decided to use is called Mocha. You can install Mocha globally, like any other npm package, as follows:

    $ npm install -g mocha

You might require security privileges when installing on Linux or OS X, which can done simply using sudo before npm.

Once installed, the Mocha command-line tool is now available. Simply executing mocha from a command line will execute the test run with a few default options.

The test runner will look for a folder named test and any .js file within. In our case, we haven't actually set up any tests yet, so executing mocha alone won't accomplish anything; instead, it will throw the following error:

 cannot resolve path

When the Mocha test runner does find .js files, it executes them like any other Node file, except it looks for a few specific keywords within the file.

Here is some sample code for a typical test block:

const expect = require('chai').expect; 
describe('The code', ()=>{ 
    beforeEach(()=>{ 
        // optional preparation for each test 
    }); 
    afterEach(()=>{ 
        // optional cleanup after each test 
    }); 
 
    it('should test something', ()=>{ 
        const something = 1; 
        // here we "expect" some condition to declare our test 
        // in this case, we expect the variable to exist 
        // more on the assertion syntax a little later 
        expect(something).to.exist; 
    }); 
    it('should test something_else', ()=>{ 
        const something_else = false; 
        // now we test a different variable against its value 
        // and expect that value to equal false 
        expect(something_else).to.equal(false); 
    }); 
}); 

The first thing Mocha will scan the file for is a describe block. A describe block is a way to define a specific group of test cases in a single line. You can have many describe blocks in a test file, and each describe block can have many specific tests. In addition, describe blocks can be nested as deeply as you like to better organize your tests.

Once a describe block is found, a few other items are executed within it. A beforeEach and afterEach block is checked to see whether there is any pretest work that needs to be executed before each test is executed. Likewise, any clean up that needs to occur between tests can be taken care of within the afterEach block.

Both of these blocks are optional and therefore, not required. A good example of when you would want to use a beforeEach block is if you need to instantiate an object that you will be testing--you would want to create a new instance before every single test. This way, whatever changes a test might push to the object will be reset and will not inadvertently affect any other tests. Likewise, any changes you've made during a test to any other related objects can be reset during an afterEach block.

Within the describe block, defining individual tests is done with it statements. Within each it statement, it's generally considered good practice to include a single expect to assert the actual test (although you can include as many expect function calls as you like, it's still only considered a single test because of the single it).

We're using the BDD style syntax when writing our suites, which allows our tests to read like user stories. Using the preceding test snippet, you can read the tests as The code should test something and The code should test something_else. In fact, if we ran the previous tests, we would see the following output:

      The code
         should test something
         should test something_else
    
      2 passing (5ms)