Take the 2-minute tour ×

In order to measure Code Coverage for JavaScript unit tests, one needs to instrument the code, run the tests and then perform post-processing.

My concern is that, as a result, you are unit testing code that will never be run in production. Since JavaScript isn't compiled, what you test should be precisely what you execute.

So here's my question, how do you handle this? One thought I had was to run Unit Testing on the production code and use that for my pass fail. I would then create a shadow of my production code, with instrumentation and run my unit tests again; this would give me my code coverage stats.

Has anyone come across a method that is a little more graceful than this?

EDIT I don't want to use browser plugins, because I then need to use a browser in order to run my unit tests.

share|improve this question
Looks like SO has an answer? stackoverflow.com/questions/53249/… I've used Jasmine effectively for unit testing but not coverage. Take a look at PhantomJS as well for headless execution. I suspect you'll have to give up some production realism to do coverage analysis, but that's normal in my experience. –  Will Jun 27 '12 at 20:41
Unfortunately, these solutions either instrument your code, or require a browser plugin. I'm updating my question to rule browser plugins out. –  Dancrumb Jun 27 '12 at 21:48

2 Answers 2

Read this on code-coverage tools for JavaScript, which has some links, though most are indeed browser extensions.

However, do consider JsTestDriver, which has code coverage support and allows for testing outside of the browser by connecting with another test tool (like HtmlUnit).

share|improve this answer

I'm not anti-testing but the very concept of trying to establish "code coverage" in client-side JavaScript strikes me as missing the point. Don't solve problems you don't have. Worry about actual risks, not every piece of code you've written. Risks in my book are code that comes into contact with third-party stuff you have no control over or a badly architected piece of an app where far too many hands are in the same cookie jar. If an entire app is brittle and prone to regression issues, all that attempting to achieve maximum code coverage does for you is enable more bad code.

Executing code in client-side JS is trivial. You should be testing everything you do thoroughly as you write it and keeping things clean and decoupled to avoid regression errors in the first place.

share|improve this answer
I agree with the last paragraph for my own code, but what if I have to take over a code base from another programmer who neither tested nor kept things clean and decoupled? –  user39685 Jan 16 '13 at 16:36
I can't really agree with this. Trying to establish 'code coverage' is not counter to effective testing; rather, it's complementary to it. Sure, blindly believing that 100% code coverage is identical to comprehensive testing would be foolish, but dismissing a desire to measure code coverage isn't the answer. It's a very useful metric when coupled with well written unit tests for identifying unexpected gaps in a test suite. –  Dancrumb Jan 16 '13 at 22:25
I've inherited some righteously awful code-bases but worrying about what the JavaScript is doing independent of the varying browsers/platforms, third-party services, and server-side thin-client shenanigans in play is 3% of the problem in client-side JavaScript in my experience. Validate at key points to narrow down sources of problems when they happen and sure, automate change-brittle sections of your codebase. After that. You only have so much time. Expand your coverage to non-problematic areas or make the brittle ones more robust? –  Erik Reppen Jan 17 '13 at 0:47

Your Answer


