The typical cycle the developer follows is something like:
This process is repeated until all tests pass and code coverage of the tests meets a certain level.
Clover provides the following features to support this development pattern:
The <clover-setup>
task takes an optional nested fileset element that tells Clover which files should be included/excluded in coverage analysis:
<clover-setup> <files includes="**/plugins/cruncher/**, **/plugins/muncher/**"/> </clover-setup>
The includes could be set using an Ant property so that individual developers can specify includes on the command line:
<property name="coverage.includes" value="**"/> <clover-setup> <files includes="${coverage.includes}"/> </clover-setup>
Developers can then use a command line like the following for Java code:
ant build -Dcoverage.includes=java/**/foo/*.java
And for Groovy code:
ant build -Dcoverage.includes=groovy/**/foo/*.groovy
Clover provides two ways of quickly viewing coverage results. The <clover-log>
task provides quick reporting to the console:
<clover-log/>
The output format from the <clover-log>
task uses the [file:line:column] format that many IDEs can parse.
The <clover-log>
task provides an option that will print a summary of coverage results to the console:
<clover-log level="summary"/>
When iteratively improving coverage on a subset of your project, you may want to include coverage data from several iterations in coverage results. Clover supports this with the span attribute which works on current reports — see Using Spans. This attribute can be used to tell Clover how far back in time to include coverage results (measured from the time of the last Clover build). To include results gathered over the last hour use:
<clover-log span="1h"/>