JavaScript Unit Tests and Code Coverage Tracking using Venus.js
Join the DZone community and get the full member experience.
Join For Freethese 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!
Published at DZone with permission of Ariya Hidayat, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments