clover-setup

Description

The <clover-setup> task initialises Clover for use with your project.

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

<clover-setup>
    <files/>
    <fileset/>
    <methodcontext/>
    <statementcontext/>
    <testsources> advanced users only
        <testclass>
            <testmethod/>
        </testclass>
    </testsources>
</clover-setup>

Parameters

Attribute	Description	Required
initstring	The Clover initString describes the location of the Clover coverage database. Typically this is a relative or absolute file reference, e.g. `${basedir}/build/clover.db`. If not specified it defaults to `.clover/clover.db`, relative to the project's base directory.	No.
enabled	This controls whether Clover will instrument code during code compilation. This attribute provides a convenient control point to enable or disable Clover from the command line	No; defaults to "`true`".
clovercompiler	After instrumentation, Clover hands off compilation to the standard Ant compiler adapter (or the compiler specified by the `build.compiler` Ant property). This attribute specifies the adapter to use. It takes the same values as the standard Ant `build.compiler` property. If you wish to specify an alternative compiler, you can either set the `build.compiler` property or use this attribute.	No.
preserve	A boolean attribute which controls whether the instrumented source will be retained after compilation.	No; defaults to "`false`".
source	The default source level to process source files at. Note that setting the source attribute on the `<javac>` target will override this setting.	No.
tmpdir	The directory into which Clover will write an instrumented copy of the source code.	No.
flushpolicy	This attribute controls how Clover flushes coverage data during a test run. Valid values are `directed`, `interval`, or `threaded`. `directed` — Coverage data is flushed at JVM shutdown, and after an inline flush directive. `interval` — Coverage data is flushed as fordirected, as well as periodically at a maximum rate based on the value of `flushinterval`. This is a "passive" mode in that flushing potentially occurs as long as instrumented code is being executed. `threaded` — Coverage data is flushed as for `directed`, as well as periodically at a rate based on the value of `flushinterval`. This is an "active" mode in that flushing occurs on a separate thread and is not dependent on the execution of instrumented code. For more information, see Using a Flush Policy.	No; defaults to "`directed`".
flushinterval	When the flushpolicy is set to `interval` or `threaded` this value is the minimum period between flush operations (in milliseconds)	No.
relative	This controls whether the initstring parameter is treated as a relative path or not.	No; defaults to "`false`".
fullyQualifyJavaLang	This should only be set to "`false`" if you have defined a variable called 'java' in your source files. If false, Clover will instrument source files without using fully qualified java.lang names.	No; defaults to "`true`".
recordTestResults	If set to "`false`", test results will not be recorded; instead, results can be added via the `<testResults>` fileset at report time. For more details please see 'Advanced Usage'.	No; defaults to "`true`".

It is important to note that the Clover compiler adapter still picks up its settings from the set of Clover Ant properties. The <clover-setup> task provides a convenient method to set these properties. This means that builds that use the Clover 1.0 property set will continue to operate as expected.

Note

Do not set the "compiler" attribute on the <javac/> task as this overrides the Clover compiler set up by <clover-setup>. Use the "clovercompiler" attribute instead.

Nested Elements of <clover-setup>

<files>

An Ant patternset, relative to the top level package (e.g. com/cenqua/clovertest), element which controls which files are included or excluded from Clover instrumentation. Use this when you wish to exclude files based on packages.

Note

The <useclass> sub-element has been deprecated and has no effect.

<fileset>

As of Clover 1.2, <clover-setup> also supports multiple Ant <filesets>. These give greater flexibility in specifying which source files are to be instrumented by Clover. This is useful when you have more than one source base and only want some of those source bases to be instrumented. This can be difficult to setup with patterns. Filesets also allow much greater flexibility in specifying which files to instrument by facilitating the use of Ant's fileset selectors. Use this when you wish to exclude files based on directory structure.

<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.

<statementContext>

Specifies a statement 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 statements you wish to include in this context. Note that when statements are tested against this regexp, whitespace is normalised and comments are ignored.	Yes.

<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.

To have test sources reported in a separate tree to your application code, use the <testsources/> element in the <clover-report/> task.

Nested elements of <testsources>

<testclass>

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

Parameters

Attribute	Description	Required
name	A regex on which to match the test class's name.	No.
super	A regex on which to match the test class's superclass.	No.
annotation	A regex on which to match the test class's annotation.	No.
package	A regex on which to match the test class's package.	No.
tag	A regex on which to match the test class's javadoc tags.	No.

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.

Parameters

Attribute	Description	Required
name	A regex on which to match the test method's name.	No.
annotation	A regex on which to match the test method's annotation.	No.
tag	A regex on which to match the test method's javadoc tags.	No.
returntype	A regex on which to match the return type of the method, e.g.: "`.*`" will match any return type. "`void`" will match methods with no return type.	No.

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-setup/>

This example is the minimal setup to use Clover. In this case, the Clover coverage database is located in the .clover relative directory.

<clover-setup enabled="${enable}"
     <files>
       <exclude name="**/cenqua/clover/**/*.java"/>
     </files>
  </clover-setup>

This example shows the use of a property, "enable", to control whether Clover instrumentation is enabled. Additionally, the instrumentation will exclude all Java source files in trees belonging to the com.cenqua.clover.* packages (please note, that even if the files belong in the src/main or src/test directory, you cannot specify src, main or test as these are directories and do not belong to the package structure. When using files, you need to filter by files or the packages as in the example above). Note that the fileset can also be referenced using a refid attribute.

<clover-setup enabled="${coverage.enable}"
     <fileset dir="src/main">
       <contains text="Joe Bloggs"/>
     </fileset>
  </clover-setup>

This example instruments all source files in the src/main directory tree that contain the string "Joe Bloggs". Ant's filesets supports a number of these selectors. Please refer to the Ant manual for information on these selectors.

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-setup flushpolicy="interval"
                flushinterval="5000"/>

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

Specifying a delegate compiler

Clover provides the optional "clovercompiler" attribute to allow specification of the java compiler to delegate to once instrumentation is completed. The attribute accepts the same values "compiler" attribute of the Ant Javac Task.

<clover-setup clovercompiler="jikes"/>

This example will pass compilation to the "jikes" compiler once instrumentation is complete.

Specifying the location of the Clover Coverage database

By default, Clover writes its internal database to the .clover/clover.db file relative to the project's basedir. To override this location, use the initstring attribute, e.g.:

<clover-setup initstring="clover-db/coverage.db"

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.

Specifying a custom test matcher

By default, Clover attempts to detect your test classes and methods. Clover's default behavior may be overridden via the following:

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

This example tells Clover to recognise 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".

Child pages

clover-setup

Description

Parameters

Nested Elements of <clover-setup>

<files>

<fileset>

<methodContext>

Parameters

<statementContext>

Parameters

<testsources>

Nested elements of <testsources>

<testclass>

Parameters

<and>

<or>

Nested elements of <testclass>

<testmethod>

Parameters

Examples

Interval Flushing

Specifying a delegate compiler

Specifying the location of the Clover Coverage database

Specifying a custom test matcher