Master JavaScript Test Cases: TDD, BDD, Mocha, Should, Nock, Istanbul

Introduction

Recently our team has placed great emphasis on test cases, so here is an analysis of test cases.

Why do we need test cases? The reason is simple: with test cases we can write high‑quality, maintainable code.

Problems

Just as earthquakes led to the invention of seismographs, test cases were created to solve specific problems.

During development we often encounter:

Requirement‑development gap

When a requirement arrives, developers may not fully understand it, leading to implementations that differ from the requirement and cause extra work.

Development‑testing gap

Development and testing can become misaligned: developers finish a feature according to their own ideas, testers evaluate it differently, resulting in disputes.

How to solve these issues? The answer is to adopt an agile software development model.

Agile Development Models

The two popular models are TDD and BDD.

TDD (Test‑Driven Development)

Tests drive development.

Focuses on developers.

Test cases constrain developers, making goals clear and designing systems that meet requirements.

BDD (Behaviour‑Driven Development)

Evolved from TDD, keeping the test‑first principle.

Focuses on design.

Describes system behavior in natural language within test code.

Combines design and test cases to drive development.

We usually choose BDD.

Testing Tools

To write test cases conveniently, we need reliable tools. Below are recommended frontend testing tools.

Mocha

Mocha, created in 2011, is one of the most popular JavaScript testing frameworks and works in browsers and Node.

Writing Mocha test scripts

A Mocha test case must contain

describe

and

it

. The describe block is a test suite, representing a group of related tests. The it block is a test case, the smallest unit of testing.

The above shows a synchronous test case.

For asynchronous code, add a

done

parameter to each

it

callback:

Should.js Assertion Library

All test cases should contain assertions. Mocha does not include an assertion library, so we need one such as Should.js. The following adds assertions to the test case:

Nock HTTP Mocking Tool

When we need to simulate HTTP response data, Nock provides a simple API for mocking.

<code>var should = require('should');
var nock = require('nock');
var teacheModel = require('teacherModel');
// define mock HTTP response
var cgiData = {
    retcode:0,
    result: {
       num: 10,
    }
};
// test method updateTeacherData
describe('测试Module.updateTeacherData()', function () {
    it('请求接口，能够正确处理数据', function(){
        // mock GET request to http://xxx.qq.com/cgi-bin/teacher/get_about returning 200 with cgiData
        nock('http://xxx.qq.com')
            .get('/cgi-bin/teacher/get_about')
            .reply(200, cgiData);

        testModule.getData({}, req, function(data){
            data.retcode.should.equal(0, 'teacher数据拿到, 不能正确处理');
        });
    });
});
</code>

Using Nock we can mock request results, allowing us to focus on model logic without depending on the actual CGI service.

Istanbul Code Coverage Tool

After writing test cases, we need to verify their quality. Istanbul provides code‑coverage metrics.

Running Istanbul on

util.test.js

yields the coverage report shown below:

Opening the generated report reveals which parts are not covered:

mochawesome Reporter

For a better visual experience, add the

--reporter mochawesome

flag when running Mocha to generate an intuitive HTML report.

Conclusion

Knowing how to write test cases is essential, but a clear set of guidelines and tutorials is needed to keep testing practices sustainable and effective.