I'm a fan of mocha + blanket for coverage: <a href="https://github.com/alex-seville/blanket" rel="nofollow">https://github.com/alex-seville/blanket</a><p>The mocha integration is incredibly easy:<p><pre><code> mocha --require blanket -R html-cov # for html output</code></pre>
This is a brilliant tool for those of us who test JavaScript. A bit of a hack, but it seems to work.<p>It's also a reason why browsers should allow some sort of tracing API for JavaScript. I know V8 and Firefox do not expose the interface because they couldn't think of a decent enough use case to justify exposing the surface area of this code. This is the use case.
In case it's useful for anyone, here is a gist of a gulpfile I use to use Istanbul to instrument my Node.js app, then run tests with Mocha and output the results:<p><a href="https://gist.github.com/medatech/76c6017cf55630b2db08" rel="nofollow">https://gist.github.com/medatech/76c6017cf55630b2db08</a>
Ah that reminds me I wrote a coverage server for istanbul in node.js. It allows testem to send coverage statics across mutliple tests/runs to reported on. It's part of a whole test running package that I'm working on open sourcing that will allow testem (which is a great test runner if you don't mind running all of your tests in one big session) to run multiple suites of tests. For instance if you have a order app and an client management app and you want separate test runs to avoid any namespace collisions the project allows you to define handlebars based templates to define your suites and run each suite with testem one at a time. Anyway here is a gist of the coverage server if it's useful to anyone:
<a href="https://gist.github.com/jaegerpicker/95c3900426d55eb9b857" rel="nofollow">https://gist.github.com/jaegerpicker/95c3900426d55eb9b857</a>
I use this all the time. This is the command I use for coverage with mocha:<p>./node_modules/istanbul/lib/cli.js cover -- ./node_modules/mocha/bin/_mocha -R spec<p>Always in my Makefile as make test-cov
Great tool, perfectly fits to the node.js ecosystem, lightweight and fast.<p>However in case you use co-mocha[1] to test your generators, istanbul won't work properly, the generators in the reports are shown as uncovered. Therefore I made a mocha fork[2] and directly applied the changes from co-mocha to the source (instead of monkey patching); it solved the problem.<p>[1] <a href="https://github.com/blakeembrey/co-mocha" rel="nofollow">https://github.com/blakeembrey/co-mocha</a>
[2] <a href="https://github.com/tfitos/mocha" rel="nofollow">https://github.com/tfitos/mocha</a>
For rails projects, if you use the teaspoon gem as test runner (<a href="https://github.com/modeset/teaspoon" rel="nofollow">https://github.com/modeset/teaspoon</a>), then you can easily get istanbul based coverage reports as well. It's a good way to see which paths your js tests take in a large project and pinpoint untested code.
Istanbul has been a godsend for my company's JS-based projects. When paired with grunt-contrib-jasmine, it gives instant visibility into how much of the client-side app is actually under test, and gives everyone an incentive to keep improving coverage.
i have some projects where the meat is in a cross domain connector. no way to test it in units. only functional test in real browsers cut it. otherwise it's just red tape testing.<p>there is zero coverage tool for this case, until browsers wake up and give me a decent Dev api like opera 12 allowed