In some cases the application you wish to test has many components running on separate nodes in a network, or even on disconnected machines. You can use Clover to test such applications, although some additional configuration is required.
When deploying your application in container environments, you should also check to ensure that Clover has sufficient permissions to function.
When deploying, please ensure you deploy your clovered version of the war/ear file. The clovered version of the war/ear will have a "-clover" in the name and can usually be found in the
For example, the filename could resemble this:
On this page:
Collecting Overall Coverage from Distributed Builds
The first step in setting up coverage from distributed builds is to configure Clover for overall coverage reporting.
Step 1: Understanding the Clover 'initstring'
At build time, Clover constructs a registry of your source code, and writes it to a file at the location specified in the Clover initialisation string (
initstring). When Clover-instrumented code is executed (e.g. by running a suite of unit tests), Clover looks in the same location for this registry file to initialise itself. Clover then records coverage data and writes coverage recording files next to the registry file during execution. See Clover Database Structure for more information.
Step 2: Choosing a Location for the Clover Registry
If you are deploying and running your Clover-instrumented code on different machines, you must provide a way for Clover to find the registry file, and provide a place for Clover to write coverage recording files; otherwise no coverage will be recorded.
Clover provides three different ways to achieve this:
- Specify an
initstringthat is a globally accessible file path
initstringshould be an absolute path to the same filesystem location, and be accessible and writable from the build machine and all execution machines. This could be a path on shared drive or filesystem.
- Specify an
initstringthat is a relative path, resolved at runtime
initstringrepresents a relative path (relative to the CWD of each execution context). To do this you need to specify
- Specify an
initstringat runtime via system properties
You can override the Clover
initstringat runtime via system properties. Two (three?) system properties are supported:To set one of these properties, you need to pass it on the command line when Java is launched, using the
If not null, the value of this property is treated as an absolute file path to the Clover registry file
If not null (and the
clover.initstringsystyem property is not set), the value of this property is used as the base directory for the file specified at compile-time in the initstring to resolve the full path to the Clover registry.
If not null (and the
clover.initstring.basedirsystem properties are not set), the value of this property is prepended to the string value of compile-time specified initstring to resolve the full path to the Clover registry.
-Dparameter: For application servers, this may involve adding the property to a startup script or batch file.
For methods two and three in the sequence above, you will need to copy the Clover registry file from the location on the build machine to the appropriate directory on each of the execution machines (as part of the test deployment process).
This needs to occur:
a. after the Clover build is complete, and
b. before you run your tests.
Once test execution is complete, you will need to copy the coverage recording files from each remote machine to the
initstringpath on the build machine in order to generate coverage reports.
Step 3: Set Your Classpath Correctly
You must put
clover.jar (or the appropriate Clover plugin jar) in the classpath for any JVM that will load classes that have been instrumented by Clover. How you go about this depends on the nature of the application you are testing and the environment you are deploying to.
In some cases, the
clover.jar must be on the classpath of the actual webserver, not just on the classpath of the webapp that is instrumented. This is to ensure Clover can properly flush its coverage data when the JVM of the webserver is shutdown.
Collecting Per-Test Coverage from Distributed Builds
The steps below require you to have carried out the previous steps on this page (related to 'Collecting Overall Coverage from Distributed Builds').
Enabling or Disabling Distributed Coverage at Runtime
Clover's Distributed Coverage feature is enabled at runtime by making use of command-line options.
This can be done without the need for re-instrumentation or compilation of source files.
Enabling Distributed Coverage
Distributed coverage can be enabled via setting this System property:
This will enable distributed coverage with default settings.
Clover also needs to know which JVM is hosting your unit tests, by providing the following system property:
Disabling Distributed Coverage
Distributed coverage can be disabled by setting this System property on either the Test or the Application JVM:
This will turn off distributed coverage for the JVM in which this is set, regardless of what was instrumented.
Distributed Per-Test Coverage in Clover will now operate when running distributed builds. Detailed reports will now be available.