EMMA: Sample Reports |
All sample reports below are accompanied by the exact steps that were used to produce them. Of course, a given coverage report can be produced in a number of ways and so the scenarios below were varied for the express purpose of showing this flexibility.
HTML report for Apache Velocity 1.4 | ||
Note that I have never done a Velocity build before this. As you can see, I
didn't even have to edit build.xml. (I needed to add
emma.jar to the lib directory but that is
unnecessary if you install EMMA as a JRE
extension). The Velocity test suite seems to fork lots of
individual testcases but all of that coverage data gets successfully
merged into coverage.ec when the ANT test target
completes. Also note how I excluded the testcase classes themselves
using an instrumentation filter.
The exact report generation steps after downloading Velocity 1.4 distribution:
>cd <velocity distribution dir>/build >ant jar >java emma instr -ix -org.apache.velocity.test.* -ip ../bin/classes -m overwrite >cp .../emma.jar lib >ant test >java emma report -r html -sp ../src/java -in coverage.em -in coverage.ec
HTML report for an interactive Swing application | ||
A similar HTML report, although a bit smaller because
SwingSet2 demo is entirely contained in the
default Java package. Unlike the Velocity example, I used the
on-the-fly instrumentation mode here: SwingSet2
classes are instrumented as they are loaded by the JVM. I could have
generated the report on application exit, but just for demo purposes I
let EMMA dump raw data to a coverage session file
(coverage.es) first via the -raw option in
order to generate whatever reports I want in a separate step.
The exact report generation steps:
>java emmarun -raw -jar .../jdk1.4.2/demo/jfc/SwingSet2/SwingSet2.jar ...kill or exit the demo... >java emma report -r html -in coverage.es -sp .../jdk1.4.2/demo/jfc/SwingSet2/src
TXT and XML reports for Sun's javac | ||
Kind of a fun example to show how line and other types of coverage can be obtained for an application for which you have no Java sources. (ok, I could probably get javac sources from Sun's SCSL download, but you get the idea.) Although it's not possible to link reports to the sources, coverage stats can still be calculated as long the classes have enough debug info compiled into them:
- [plain text report (1.4 Kb)]
-
An informal format for quick viewing in a command shell window or a spreadsheet (uses tabs for column separators, so probably doesn't look pretty in a browser). This report depth defaults to just showing the overall and package summaries.
- [XML report (636 Kb)]
-
A structured format for "integration". This report depth defaults to method level, which explains the size of the file. Since there aren't any existing tool that do integration yet, this format will likely change in the future (to support efficient XSLT work etc).
Again, I used the on-the-fly mode here and for a change I specified the -f option to make sure that all javac implementation classes were in the report, not just the ones loaded at runtime. Because JDK's tools.jar contains a lot more than just javac implementation, note the use of an inclusion filter to limit things to com.sun.tools.javac and subpackages. The exact report generation steps (javac compiling the SwingSet2 demo sources):
>mkdir classes
>java emmarun -f -r txt,xml -ix +com.sun.tools.javac.* -cp .../jdk1.4.2/lib/tools.jar \
com.sun.tools.javac.Main -d classes .../jdk1.4.2/demo/jfc/SwingSet2/src/*.java
