This page contains best practices for using Clover for Maven 2 and 3.
On this page:
- Test Optimization in a CI environment
- Test optimization on the desktop
- Combining build optimization with site coverage reporting
- Test optimization across a multi-module project
- Using clover:setup for non-forked life cycle
- Cross compilation using Groovy
- Coloring test optimization
- Build Profiles
Test Optimization in a CI environment
There are two recommended ways to utilize Clover's test optimization in a CI (Continuous Integration) environment, either using a Profile, or to run the goals directly.
NB. Clover Test Optimization will not work if you have added the
clover-maven-plugin to the default build section of the pom with an execution binding the 'instrument' goal.
Setting up a CI profile
- Add a
pom.xml. profile to the project's
- Create a new 'Gateway' build plan in your CI server. A 'Gateway' build plan is one that gets run before any others and if successful, triggers any subsequent builds.
The gateway plan should execute the verify phase, with the 'clover.optimize' profile activated. Example:
If your build plan is configured to do a full clean checkout before each build — you will need to ensure the Clover snapshot file is stored in a location that will not be removed between builds. The following configuration added to the
pom.xmlis one option:
Beware however, that this set up will instrument your source and test files and compile them to the usual Maven output location. If you run this command:
then you will be deploying class files that have been instrumented by Clover .
Running the Clover goals directly
Add a new build plan with the following command line:
Test optimization on the desktop
Running Clover's test optimization locally is very advantageous. This is achieved using theprofile that can be activated like so:
Combining build optimization with site coverage reporting
Maven2 will merge any executions defined in the default build section of the pom, with those defined in a profile. It is therefore recommended practice to always use two profiles — one for test optimization and one for generating a Clover report when you generate a site. The
clover:instrument goal forks the build lifecycle ensuring that Clover instrumented sources are kept completely separate from production sources. This also means that your tests get run twice — which is obviously not desirable in an optimized build.
Theprofile is an example of a build profile to activate when running this command:
Using separate profiles for site generation and Test Optimization is currently the recommended way to have both a site and a Test Optimization Clover build configured in the same
Test optimization across a multi-module project
By default, Clover will generate a new
clover.snapshot file for each module. This means, that if you have tests in module A that cover code in module B, and you modify code in module B, the tests in module A will not be run. You can achieve the desired behavior however, by configuring Clover to use a single
clover.snapshot for the entire project:
Using clover:setup for non-forked life cycle
The clover:setup is designed to make integration with integration and functional tests a lot simpler than using the forked lifecycle that comes with clover:instrument. It also has the added advantage of not having to run your tests twice.
Executing clover:setup does the following:
- Instruments all source and test files found in
- Copies the instrumented source files to
- Redirects the Maven project's source and test directories to
instrumented. Subsequent plug-ins in the build life cycle then use these locations as the source directories.
Therefore, executing the following line will instrument all source and test files, compile the instrumented source files, run all tests and then install the compiled and instrumented classes.
WARNING: It is not recommended to deploy your Clover instrumented classes to an external Maven repository.
Note: clover:setup will automatically bind itself to the 'process-sources' phase if defined in the goals list of the plugin's executions.
Cross compilation using Groovy
If you are using cross-compilation with Groovy code, you should ensure that the clover-maven-plugin
:setup goal runs before the GMaven Plugin's
gmaven:generateStubs goal in your
pom.xml. Otherwise, you may end up with errors when running the Clover-for-Maven 2 plugin.
Alternatively, if you run
clover:setup directly from the
mvn command line, then this Clover goal will run before the
gmaven:generateStubs goal and you will avoid these errors when cross-compiling Groovy code.
Coloring test optimization
If your terminal supports ANSI escape codes, run your Maven build with the
-Dansi.color flag. Currently a few important log messages dealing with Clover's Test Optimization will be logged in color:
The following profiles can be used directly in the pom.xml. This avoids the need to modify the ~/.m2/settings.xml file.
Clover Optimize Profile
Clover Optimize, Report, Log and Check Profile