Menu
To calculate the code coverage percentage, simply use the following formula: Code Coverage Percentage = (Number of lines of code executed by a testing algorithm/Total number of lines of code in a system component) * 100.
Code coverage tools are available for many programming languages and as part of many popular QA tools. They are integrated with build tools like Ant, Maven, and Gradle, with CI tools like Jenkins, project management tools like Jira, and a host of other tools that make up the software development toolset.
Code coverage tools use static instrumentation in which statements monitoring code execution are inserted at critical junctures in the code. Now, adding instrumentation code does result in increased execution time and code length.
With that being said it is generally accepted that 80% coverage is a good goal to aim for. Trying to reach a higher coverage might turn out to be costly, while not necessary producing enough benefit. The first time you run your coverage tool you might find that you have a fairly low percentage of coverage.
Does your scripting language generate bytecode? Does it generate debug metadata? If so, bytecode instrumentation is probably the way to go. In fact existing tools will probably work (perhaps with minimal modification).
The typical problem with such tools that they are written to work with Java and assume that a class com.foo.Bar.class corresponds to a file com/foo/Bar.java. Unwinding that assumption can be tedious.
EMMA is a ClassLoader that does byte-code re-writing for code-coverage collection in Java. The coding style is a little funky, but I recommend reading source code for some ideas.
If your scripting language is interpreted then you will need a higher-level class loader (at a source level) that hooks into the interpreter.
You can also get the source from a Open Source code coverage tool and learn from it.
Thxm, Mc! http://asm.objectweb.org/ is another one. Excellent documentation on byte code instrumentation, but nothing "directly" aimed at writing a coverage tool - just some hints or ideas.
You might also want to use something like BCEL to analyse which lines of source actually exist in the byte-code. You don't want to report that things like blank lines and comments haven't been covered.
If you're talking about ColdFusion (which I assume you are from the tags) then I'm not sure this is doable but I may be very wrong here...
IIRC, When CF compiles it essentially compiles into a interpreted form of the CFML as a plain old java source file, this is then compiled into the class. Therefore, any instrumentation that you may have will apply to the intermediary version rather than the CFML itself.
Saying that though, Adobe have got the CF debugger now which can step though code, so please prove me wrong - I'd love code coverage in CFML.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With