site.data.xdocs.samples.xml Maven / Gradle / Ivy
Go to download
Show more of this group Show more artifacts with this name
Show all versions of emma_ant Show documentation
Show all versions of emma_ant Show documentation
EMMA is a fast Java code coverage tool based on bytecode instrumentation. It differs from the existing tools by enabling coverage profiling on large scale enterprise software projects with simultaneous emphasis on fast individual development.
The newest version!
<?xml version="1.0"?>
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.2//EN"
"http://apache.org/forrest/dtd/document-v12.dtd"
[
<!ENTITY PROD "EMMA">
<!ENTITY prod "emma">
]>
<document>
<header>
<title>&PROD;: Sample Reports</title>
</header>
<body>
<p>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.</p>
<section><title>HTML report for Apache Velocity 1.4</title>
<p><fork href="coverage_sample_a/index.html"><img
src="coverage_sample_a/thumb.png" alt="HTML report for Apache Velocity
1.4"/></fork> <em>Note that I have never done a Velocity build before this.</em> As you can see, I
didn't even have to edit <strong>build.xml</strong>. (I needed to add
∏.jar to the <strong>lib</strong> directory but that is
unnecessary if you <fork
href="ext:reference.install.note.jreext">install &PROD; as a JRE
extension</fork>). The Velocity test suite seems to fork lots of
individual testcases but all of that coverage data gets successfully
merged into <strong>coverage.ec</strong> when the ANT test target
completes. Also note how I excluded the testcase classes themselves
using an <fork href="ext:reference.instrset.overview">instrumentation filter</fork>.</p>
<p>The exact report generation steps after downloading Velocity 1.4 distribution:</p>
<source><![CDATA[
>cd <velocity distribution dir>/build
>ant jar
>java ]]>∏<![CDATA[ instr -ix -org.apache.velocity.test.* -ip ../bin/classes -m overwrite
>cp .../]]>∏<![CDATA[.jar lib
>ant test
>java ]]>∏<![CDATA[ report -r html -sp ../src/java -in coverage.em -in coverage.ec]]></source>
</section>
<section><title>HTML report for an interactive Swing application</title>
<p><fork href="coverage_sample_b/index.html"><img
src="coverage_sample_b/thumb.png" alt="HTML report for
SwingSet2"/></fork> A similar HTML report, although a bit smaller because
<code>SwingSet2</code> demo is entirely contained in the
default Java package. Unlike the Velocity example, I used the
<em>on-the-fly</em> instrumentation mode here: <code>SwingSet2</code>
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 &PROD; dump raw data to a coverage session file
(<strong>coverage.es</strong>) first via the <fork
href="ext:reference.tool-ref.run.raw.cmdline">-raw</fork> option in
order to generate whatever reports I want in a separate step.</p>
<p>The exact report generation steps:</p>
<source><![CDATA[
>java ]]>∏<![CDATA[run -raw -jar .../jdk1.4.2/demo/jfc/SwingSet2/SwingSet2.jar
]]><em>...kill or exit the demo...</em><![CDATA[
>java ]]>∏<![CDATA[ report -r html -in coverage.es -sp .../jdk1.4.2/demo/jfc/SwingSet2/src]]></source>
</section>
<section><title>TXT and XML reports for Sun's <strong>javac</strong></title>
<p>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 <strong>javac</strong> 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:</p>
<dl>
<dt>[<fork href="coverage_sample_c/coverage.txt">plain text report (1.4 Kb)</fork>]</dt>
<dd>
<p>An informal format for quick viewing in a command shell window
or a spreadsheet (<em>uses tabs for column separators, so probably
doesn't look pretty in a browser</em>). This report <fork
href="ext:reference.tool-ref.reportdepth">depth</fork> defaults to
just showing the overall and package summaries.</p>
</dd>
<dt>[<fork href="coverage_sample_c/coverage.xml">XML report (636 Kb)</fork>]</dt>
<dd>
<p>A structured format for "integration". This report
<fork href="ext:reference.tool-ref.reportdepth">depth</fork>
defaults to <code>method</code> 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).</p>
</dd>
</dl>
<p>Again, I used the on-the-fly mode here and for a change I specified the
<fork href="ext:reference.tool-ref.run.f.cmdline">-f</fork> option to make sure
that all <strong>javac</strong> implementation classes were in the
report, not just the ones loaded at runtime. Because JDK's
<strong>tools.jar</strong> contains a lot more than just javac
implementation, note the use of an <fork
href="ext:reference.instrset.filters">inclusion filter</fork> to limit
things to <code>com.sun.tools.javac</code> and subpackages. The
exact report generation steps (<strong>javac</strong> compiling the
<code>SwingSet2</code> demo sources):</p>
<source><![CDATA[
>mkdir classes
>java ]]>∏<![CDATA[run -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]]></source>
</section>
</body>
</document>