I started work at Mozilla in May, and haven't had a chance to update my blog since then. I've been working on a project to implement the DOM in JavaScript. One of the interesting side-projects that has come out of this is a code coverage tool for SpiderMonkey (Mozilla's js interpreter). I'm calling it CoverMonkey, and have just created a repo for it on github. Take a look at some example output.
Debug builds of SpiderMonkey have a -D option that causes them to output opcode-by-opcode disassembly of every file they've run, along with execution counts for every opcode. CoverMonkey analyzes this output and displays coverage statistics and generates color-coded versions of your source code to highlight uncovered and partially covered lines.
The first big caveat about CoverMonkey is that this is not a tool you can use in the browser. It works with standalone versions of SpiderMonkey only. So it is only useful if you're using pure JavaScript. The second caveat is that you'll need a debug build of SpiderMonkey, which means that you'll probably have to build it yourself. Another, smaller caveat: CoverMonkey is a JavaScript program, but unfortunately SpiderMonkey cannot create files, so CoverMonkey requires Node.
@__DavidFlanagan
Nice!
I'm curious, how do you define "partially covered" (in the output) ?
Cedric,
When only some of the bytecodes associated with a given line of source code have been executed (think var w = x ? y : z;) then that source code line is "partially executed". The entire line gets marked yellow in the HTML output to indicate a coverage problem.
The only way (for now at least) to figure out what part of the line is uncovered is to look at the bytecodes. If you use the -a option to CoverMonkey, then you can click on any line (in the HTML output) and see the bytecodes and per-bytecode execution counts associated with it.