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.

  • 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, 2012 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, 2012 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).


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.

  • 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, 2013 at 16:36
  • 1
    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, 2013 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? Jan 17, 2013 at 0:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.