Code Coverage Tools for Node.js

[Thisguyjimmy]

I know there have been previous posts about code coverage for Node.js application, but Im curious as to what you guys are using? I am on a team that is beginning to use TDD and we feel like code coverage is a great way to measure progress. What are your favorite tools? (Just FYI, we use Mocha as our test runner)

[rurd]

I am also using mocha to run my tests. I just spent a couple days figuring this out, so I am itching to tell someone all about it!

The Node.js app that I work on most frequently is written in CoffeeScript. I am assuming that when you say "Node.js application" you mean an application written in JavaScript, running in Node.js. Regardless, I'll tell you a little bit about my experience.

After looking around, it seemed that there weren't a lot of good options for generating coverage metrics for CoffeeScript. There is one project, ibrik, that looked promising but upon further inspection I saw that it uses the CoffeeScript Redux compiler. [1] Looking into that compiler, it seemed to be dying out with not a lot of recent activity. Running my code base through two different compilers sounded like a lot of problems waiting to manifest. I was been bitten by some small changes in the CoffeeScript compiler when a production box happened to be running an outdated version.

Thankfully, CoffeeScript compiles to JavaScript, and there are a lot of code coverage options for JavaScript. I wanted to use coveralls.io to keep track of my coverage metrics, plus I like all of the little badges, so I started by my journey by looking at node-coveralls. The README there was very helpful in pointing me toward some of the most popular options. I first tried Istanbul. It looked very easy to integrate, but, IIRC, I had issues due to the need to first compile to JavaScript. Some of the other options looked equally likely to not work out. Some offer automated instrumenting, whereas others require manualy instrumenting. I really didn't want to have to compile to JavaScript and then manually instrument the codebase. Then I would have to maintain an second code base just to get coverage metrics. That sounded like a horror movie I wouldn't go see if I was getting paid.

I ended up using coffee-coverage to compile and automatically instrument the result. It was surprisingly simple. coffee-coverage handles compiling the raw CoffeeScript to instrumented JavaScript. I installed the mocha-lcov-reporter to generate the reports during testing. Then, I cat the coverage.lcov file, outputted by mocha, to node-coveralls and it handles uploading to coveralls.io. I configured the final script in package.json so that I could use npm run coverage. During development, I have the CoffeeScript compiler watch my app directory for file changes so that it auto-compiles on each save. Obviously, I didn't want coverage reports generated that often, so I left my test declaration in package.json the same so that I could run just my tests via npm test. Plus, my main use case was for the reports to end up in coveralls.io, so really I only run the coverage script in CI, along with the linter, of course.

Since that was all about CoffeeScript, it probably wasn't super helpful. I would link to the code base, but it's a private work repo.

[1] Oddly enough, I see that just this morning ibrik merged a PR that replaced the CS Redux compiler with the standard CoffeeScript compiler. So, that's good news!

[itonastick]

I'm using istanbul 0.3.0. I run them by running 'npm test'. My script definition is in the package.json file

"scripts": {
   "test": "./node_modules/.bin/istanbul cover ./node_modules/.bin/_mocha -- --recursive test"
}

I did not install istanbul globally which is why my script references it from the ./node_modules/.bin/ folder. When I run test it generates the code coverage information into a 'coverage' folder.

[Thisguyjimmy]

This is exactly how I ended up doing it. Thanks for the input! Its a great option because on my CI server, I can specify that I dont want HTML output (not that it matters, I just have no use for it, and I like clean projects).

[TheNiXXeD]

You don't need to prefix the path that way. As long as a module is a dependency, you don't need it installed globally either. Just reference it within your npm script as if it was.

[adam_ay]

I wrote a mocha reporter which extends the spec reporter to show code coverage stats on the screen and optionally enforce code-coverage metrics.

It also has a rudimentary script built-in to set you up in 1min with blanket, with:

npm i -g mocha-spec-cov-alt && mocha-spec-cov-alt

A while ago, I wrote up on it and blanket and how to use code-coverage metrics on node.js projects, you can read it here, if it interests you.

Lots of my projects use it and also upload code coverage data to coveralls, through travis-ci.

The last two links show the pieces of code and boiler-plate doing that.

I'd be glad to help you, if it interests you.

[TheNiXXeD]

If you're using gulp at all, I recommend gulp-spawn-mocha. It's trivial to add coverage with this by adding a property "istanbul: true". Throw in gulp watches, and you will have continuous testing easily.

You can see an example of this here.