views:

263

answers:

1

but most of our javascript code is run serverside and can't be executed in a browser. the ecmascript implementation used is Rhino.

i have checked all the javscript coverage tools that where suggested, like the ones here:

http://stackoverflow.com/questions/53249/are-there-any-good-javascript-code-coverage-tools

the suggested coverage tools are strongly geared towards testing browser-JS (e.g. the jscoverage tool has a builtin webserver delivering JS to be tested for coverage).

+2  A: 

If you have a Javascript interpreter, you should be able to modify it to collect test coverage data directly.

If the problem is to detect test coverage, and you don't have access to the internals of the interpreter (e.g., the Firefox solution etc.), then you need to instrument the JavaScript source code directly, and use JavaScript itself to collect test coverage data. This is the answer that deserves the OP's extra points :-}

A standard scheme for doing this instrumentation is to apply a program transformation system to the problem, where the the PTS has access to a JavaScript grammar and can apply probe-inserting transformation rules. A complete description of how to accomplish this can be found in the paper, "Branch Coverage for Arbitrary Languages Made Easy", found at http://www.semdesigns.com/Company/Publications/TestCoverage.pdf The site has test coverage tools for a variety of langauges, including C, C++, C#, Java, COBOL and PHP. We never got around to JavaScript but the same approach would work fine. (There's a PTS at this site that can/does process JavaScript as a starting point).

Once you've collected the test coverage data, you have the problem of displaying it in a useful form. You can just print out "funciton foo executed" but that's not very informative by itself. Ideally you'd like to display each line or block annotated with its execution ("coverage") status. A good display will merge coverage status for individual contiguous lines into a block so that it is evident which blocks of text have been executed, and which have not. Finally, you want some kind of summary, showing the coverage status of each code block and each containing block of code (function, package, file, directory, ...) so that you can see the coverage status of the entire software system at varying degrees of granularity. Managment especially likes reports like this.

Ira Baxter
you get the extra point :) though of course i was hoping for a "take this tool, do that"-solution.i managed to instrument the code with http://siliconforks.com/jscoverage/ - its a bit clumsy, but starting from that i was able to extract data, which doesn't seem all too correct. i'll have to dig into this branch-stuff you link to.
oberhamsi
JSCoverage only instruments physical lines of text (see thier documentation). If you've formatted your code perfectly, this might give you good test coverage data. You really want a tool that instruments text based on the grammar as I've described.
Ira Baxter