This documentation relates to an earlier version of Clover.
View

Unknown macro: {spacejump}

or visit the current documentation home.

This page contains instructions on how to tune Clover's performance when running your builds and measuring code coverage.

On this page:

Configure 'Unique Coverage' Tracking

Unique coverage relates to a line of code that was hit by only one test. Unique coverage tracking can be switched off to reduce CPU & memory usage when running Clover.
You can configure unique coverage reporting in the following Clover components:

Set Instrumentation to "method level" (when using Test Optimization)

If you use Clover in your build purely for Test Optimization purposes and not for coverage reporting, you can reduce the granularity of Clover instrumentation from statement to method level. The 'instrumentationLevel' attribute set to method level allows for speedier instrumentation, compilation & test execution.

This speeds up the build at the loss of some accuracy. This is the setting to use if you want to improve Clover's performance. When this attribute is set to 'statement' (the default), the builds will take longer but the optimization intelligence will also be stronger.

You can configure instrumentation level in the following Clover-for-Ant tasks:

See the Ant Task Reference for more information.

Runtime Performance Settings

During your test runs, Clover tries to record total code coverage and per-test code coverage as efficiently as possible but defaults to settings best for applications which are not highly CPU intensive. If your application is highly CPU intensive and code coverage recording is causing slow running tests, the following options may assist:

  • Supply this option to the JVM running your tests:

    -Dclover.pertest.coverage=diff

    This changes the way per-test coverage is recorded at runtime to work faster for CPU intensive applications.

  • Supply this option to the JVM running your tests:

    -Dclover.pertest.coverage=off

    This tells Clover to not record any per-test coverage data at runtime. With this you gain a faster running time for CPU intensive applications, although you lose per-test coverage information.

  • If you fork your unit tests, this must be passed to the forked JVM as a command line argument in Ant, Maven or the Eclipse or IDEA Intellij unit test launchers through their respective dialogs; if you don't fork your tests, this must be supplied to Ant through the ANT_OPTS environment variable or to Maven through the MAVEN_OPTS variable.
  • No labels



Log a request with our support team.



Raise an issue for our developers.



See answers from the community.



Update our documentation.

Except where otherwise noted, content in this space is licensed under a Creative Commons Attribution 2.5 Australia License.