Something that's built-in, and works without massive reconfiguration would be a big help to developers and something that no-one else does out of the box. State of the art as far as I can see: - https://code.google.com/p/script-cover/ has never worked for me. Currently it breaks GCLI. - http://www.zachleat.com/web/javascript-code-coverage-tool-for-firebug/ is 5 years old and version 0.1. I didn't try to get it working for obvious reasons. Also from what I can see it isn't line-by-line, only function by function. - http://hrtimer.mozdev.org/ (hrcov) is similar - http://siliconforks.com/jscoverage/ looks to be the most popular (see http://stackoverflow.com/questions/53249/are-there-any-good-javascript-code-coverage-tools) but it's too hard to configure - Same for https://code.google.com/p/js-test-driver/wiki/CodeCoverage It seems to me that coverage analysis either has to be done via code-instrumentation or done at a VM level. The problem with instrumentation is that: - it's likely to be hard to configure - it can break working programs - it can be very slow Since JSD2 can help here, we should be all over this like a rash.

Forgot to mention Cedricv work on this, which is good in that it works with chrome code, however it is hard to get going especially on windows.

(In reply to Joe Walker from comment #1) > Forgot to mention Cedricv work on this, which is good in that it works with > chrome code, however it is hard to get going especially on windows. There is a plan to integrate (an improved) CodeInspector in the browser, see bug 719137. For code coverage reports, the PCCounts API seems simpler and have less overhead than JSD2 imho.

(In reply to Joe Walker from comment #1) > Forgot to mention Cedricv work on this, which is good in that it works with > chrome code, however it is hard to get going especially on windows. Oh, and actually now that the PCCounts API landed, it would be possible to reboot (the API has changed quite a bit) the "live coverage" add-on (http://github.com/neonux/CodeInspector) and have it work on any recent Firefox release.

Off the top of my head, I can think of two very divergent ways to approach this. It's entirely possible that you've got something else in mind, Joe. 1. provide an API to web content that test runners (eg QUnit) could use to get coverage statistics 2. provide a UI in the script view that shows which lines have been touched and which ones haven't. maybe some additional UI with statistics

(In reply to Kevin Dangoor from comment #4) > Off the top of my head, I can think of two very divergent ways to approach > this. It's entirely possible that you've got something else in mind, Joe. > > 1. provide an API to web content that test runners (eg QUnit) could use to > get coverage statistics > > 2. provide a UI in the script view that shows which lines have been touched > and which ones haven't. maybe some additional UI with statistics 3. Both :)

I did some work on a possible API here: https://etherpad.mozilla.org/devtools-js-coverage

You might be interested by this thread: https://groups.google.com/forum/#!topic/mozilla.dev.platform/lURoeup0ahQ