Description

The <clover-instr> task produces instrumented versions of sets of Java source files. These can then be compiled in place of the original source to produce an instrumented Java build.

The basic nesting of elements within the <clover-instr> task is as follows:

Parameters

Nested Elements of <clover-instr>

<distributedCoverage>

This element turns on Clover's distributed coverage feature, enabling the collection of per-test coverage data, when your test environment requires more than one JVM (Java Virtual Machine).

Parameters

All attributes are optional.

<fileset>

Specifies a set of source files to instrument.

<methodContext>

Specifies a method Context definition. See Using Coverage Contexts for more information.

Parameters

Attribute	Description	Required
name	The name for this context. Must be unique, and not be one of the reserved context names (see Using Coverage Contexts).	Yes.
regexp	A Perl 5 Regexp that defines the context. This regexp should match the method signatures of methods you wish to include in this context. Note that when method signatures are tested against this regexp, whitespace is normalised and comments are ignored.	Yes.
maxComplexity	Match a method to this pattern if its cyclomatic complexity is not greater than maxComplexity. In other words - all methods with complexity <= maxComplexity will be filtered out.	No.
maxStatements	Match a method to this pattern if its number of statements is not greater than maxStatements. In other words - all methods with statements <= maxStaments will be filtered out.	No.
maxAggregatedComplexity	Since 3.1.10. Match a method to this pattern if its aggregated cyclomatic complexity is not greater than maxAggregatedComplexity. In other words - all methods with aggregated complexity <= maxAggregatedComplexity will be filtered out. Aggregated complexity metric is a sum of the method complexity and complexity of all anonymous inline classes declared in the method.	No.
maxAggregatedStatements	Since 3.1.10. Match a method to this pattern if its number of aggregated statements is not greater than maxAggregatedStatements. In other words - all methods with aggregated statements <= maxAggregatedStaments will be filtered out. Aggregated statements metric is a sum of the method statements and statements of all anonymous inline classes declared in the method.	No.

 

What is the difference between maxComplexity and maxAggregatedComplexity or maxStatements and maxAggregatedStatements?

Aggregated metrics calculate method statements/complexity including the code of all anonymous inline classes declared inside the method. Thanks to this, it is possible to distinguish between a trivial single-statement method like:

int getNumber() {
   return number;
}

and a single-statement method which actually returns more complex data, like:

ActionListener getListener() {
   return new ActionListener() {
       public void actionPerformed(ActionEvent e) {
           System.out.println("statement #1");
           System.out.println("statement #2");
           System.out.println("statement #3");
       }
   };
}

 

If you would use a method context filter with maxStatements attribute, like the following:

<methodContext name="trivial" regexp=".*" maxStatements="1">

then both getNumber() and getListener() methods would be filtered-out, because each of them contains only one statement: "return <xxx>".

 

If you would use new maxAggregatedStatements, for instance:

<methodContext name="trivial" regexp=".*" maxAggregatedStatements="1">

then the getNumber() would be filtered-out and the getListener() method would not be filtered out (because it contains 4 statements in total - 1 "return" statement from the method itself and 3 "System.out.println()" statements from anonymous class).

 

Regular expression tip:

If you would like to filter-out all methods, except those having a specific name, you could write a negative-look-ahead regular expression. For example:

<methodContext name="trivial" regexp="^(?!.*(getRunnable|getListener)).*$" maxStatements="1"/>

will filter-out all methods having not more than one statement, except those which are named getRunnable or getListener.

 

<profiles>
  <profile name="default" coverageRecorder="FIXED|GROWABLE|SHARED">
    <distributedCoverage/> <!-- optional -->
  </profile>
  <profile .../>
  <!-- more profiles -->
</profile>

<testsources>

<testsources> is an Ant fileset which should only be used if Clover's default test detection is not adequate. Clover's default test detection algorithm is used to distinguish test cases if this element is omitted.

Nested elements of <testsources>

<testclass>

<testclass> can be used to include only specific test classes.

Parameters

For more information about regular expressions, please visit http://java.sun.com/j2se/1.4.2/docs/api/java/util/regex/Pattern.html#sum.

<and>

<and> can be used to specify multiple instances of <testclass>, all of which must be matched for a class to be detected as a test, e.g.:

<testsources dir="tests">
<and>
  <testclass annotation="Specification"/>
  <testclass annotation="Test"/>
</and>
<testsources>

In this example, a class will only be recognised as a test if it has "Specification" and "Test" annotations.

<or>

<or> can be used to specify multiple instances of <testclass>, any of which must be matched for a class to be detected as a test, e.g.:

<testsources dir="tests">
<or>
  <testclass name=".*Spec"/>
  <testclass name=".*Test"/>
</or>
<testsources>

In this example, a class will be recognised as a test if its name matches ".*Spec", or its name matches ".*Test".

Nested elements of <testclass>

<testmethod>

<testmethod> can be used to perform more fine grained detection of test methods.

Clover matches methods only; it does not match constructors (CLOV-1339).

Parameters

Note that you can include multiple instances of <testmethod>, in which case they will be treated as 'or' clauses, e.g.:

<testsources dir="tests">
  <testclass>
    <testmethod annotation="Specification"/>
    <testmethod name="^should.*"/>
    <testmethod name="^must.*"/>
  </testclass>
<testsources>

In this example, a method will be recognised as a test if its annotation is "Specification", or its name matches "^should*", or its name matches "^must*".

Examples

<clover-instr srcdir="src" destdir="instr"/>

Produce an instrumented copy of all source files in the srcdir into the destdir. The Clover registry is at the default location.

<clover-instr destdir="instr"/>
     <fileset dir="src">
       <include name="**/*.java"/>
     </fileset>
</clover-instr>

This example achieves the same as the first example, but using an embedded fileset.

<clover-instr destdir="instr"/>
     <testSources dir="src">
         <include name="**/*Test.java"/>
         <testclass name=".*Test">
             <testmethod name=".*Bag.*"/> <!-- only the Bag related tests -->
         </testclass>
     </testSources>
</clover-instr>

This example produces an instrumented copy which recognises all of the following as tests: classes in the directory "src"; classes in files whose names end with "Test"; methods whose names contain with "Bag".

Interval Flushing

By default Clover will write coverage data to disk when the hosting JVM exits, via a shutdown hook. This is not always practical, particularly when the application you are testing runs in an Application Server. In this situation, you can configure Clover to use 'interval' flushing, where coverage data is written out periodically during execution:

<clover-instr flushpolicy="interval" flushinterval="5000" srcdir="src" destdir="instr" />

The "flushinterval" defines in milliseconds the minimum interval between coverage writes.

Specifying the location of the Clover Database.

By default, Clover writes its internal database to the .clover directory relative to the project's basedir. To override this location, use the initstring attribute.

<clover-instr initstring="clover-db/coverage.db" srcdir="src" destdir="instr"/>

This example will use clover-db/coverage.db as the location for the Clover database. Note that the directory clover-db should exist before running this task.

Troubleshooting

Clover does not support parallel instrumentation

You cannot use <parallel/> task for code instrumentation, for instance:

<target name="instrument">
  <parallel>
    <clover-instr srcdir="module1" destdir="module1-instr" .../>
    <clover-instr srcdir="module2" destdir="module1-instr" .../>
  </parallel>
</target>

will produce error message like:

[clover] Error finalising instrumentation:
   [clover] java.io.IOException: Failed to move tmp registry file /myproject/.clover/clover3_1_6.db.tmp to final registry file