JavaScript Unit Tests and Code Coverage Tracking using Venus.js

these days, having enough unit tests for a javascript-based web application/library is the bare minimum. ideally, the code coverage of those tests is also monitored in a day-to-day development situation. fortunately, this is easy to do with a modern test runner such as venus.js .

named after the famous venus flytrap , venus.js was originated at linkedin engineering group to facilitate its javascript testing activities. venus.js is pretty comprehensive, it supports unit tests written for a number of test libraries : mocha (default), jasmine, and qunit. venus.js is easy to install and to use, i recommend reading its excellent getting started tutorial.

for the demonstration of code coverage, i prepare a git repository bitbucket.org/ariya/coverage-istanbul-venus . if you want to follow along, just clone it and check its contents.

first, let’s take a look at the code we want to test. this is just a diy implementation of the square root function, it can’t be simpler than:

var my = {
    sqrt: function(x) {
        if (x < 0) throw new error("sqrt can't work on negative number");
        return math.exp(math.log(x)/2);
    }
};

in order to maximize the test coverage, the unit tests for the above my.sqrt() function needs to check for normal square root operation and also when it is supposed to throw an exception. this is available in the test/test.sqrt.js file (based on mocha ) which looks like the following:

/**
* @venus-library mocha
* @venus-code ../sqrt.js
*/
describe("sqrt", function() {
  it("should compute the square root of 4 as 2", function() {
    expect(my.sqrt(4)).to.equal(2);
  });
});

one notable feature of venus.js is its zero-configuration design. in the above example, we don’t need to write any html to serve the code and the test. venus.js uses an annotation approach. you can see the use of @venus-code to specify the file containing the code we want to test (i.e. the implementation of my.sqrt ) and @venus-library to choose the testing library (i.e. mocha). everything else will be taken care of automatically.

if venus.js is properly installed, executing the test is a matter of running:

venus test/test.sqrt.js -e ghost

which gives the following result:

in the test invocation, the option -e ghost indicates that the tests are to be executed headlessly using phantomjs (again, another nice built-in feature of venus.js). of course, venus.js supports other testing environments and it can run the tests on real web browsers or even via selenium grid or sauce labs.

how to show the code coverage of the tests? it is a matter of adding another option:

venus test/test.sqrt.js -e ghost --coverage

behind the scene, venus.js uses istanbul , an excellent javascript instrumentation and code coverage tool. running the test with coverage tracking will add a few more lines of report. thanks to istanbul, all three types of code coverage (statements, functions, branches) will be tracked accordingly.

another very useful feature of venus.js is the ability to mix-and-match tests written using a different library. this is illustrated in the example repo. instead of only test/test.sqrt.js , you also spot two additional files with their own set of unit tests: test/test.extensive.js and test/test.error.js . the former adds more checks on the square root functionality (probably excessive, but you got the point) while the latter detects some more corner cases. what is interesting here is that test.extensive.js relies on jasmine while test.error.js is written using qunit .

if you check the package manifest, what npm test actually runs is:

venus test --coverage -e ghost

in other words, venus.js will locate all the test files in the test/ directory and execute them. in this case, we have three (3) test files using different test libraries and venus.js will handle them just fine. isn’t it nice?

in the past, i have explained the use of karma and istanbul to track code coverage of javascript unit tests written using jasmine , qunit , and mocha . however, if karma is not your cup of tea or if your different subteams would like to use different test libraries, then perhaps venus.js can be the solution for you.

have fun trapping those bugs!