Click on the triangle next to the question to reveal the answer


Clover can run on a build server or a developer's workstation depending on your preference and environment.


Bamboo and Clover can currently work together in the following ways:

  • See how much of your build is actually being tested
  • Compare statement, method and conditional branch coverage
  • Compare total lines-of-code to just non-comment lines-of-code
  • Track number of files, methods, classes and packages in each build

Here are instructions on how to integrate Bamboo and Clover.

There is also a Coverage Plugin available from Bamboo.


This currently under internal testing. We expect it to be released in the coming weeks.


Clover can display historical reports for sets of coverage data and other metrics collected over time for a project.


Clover has extensive integration with Apache ANT. Please view our documentation on step by step instructions.


A plugin is available from Hudson that provides you coverage reports from Clover.


Clover doesn't run tests directly; it integrates with existing test runners in the Ant, Maven, Eclipse and IntelliJ IDEA environments. Clover measures per-test coverage by specially instrumenting your JUnit or TestNG test classes. You can also define your own test detector to match other, homegrown test methods.

If you run manual tests, Clover can still measure code coverage for these tests. It will not be reported at the per-test level.


Clover is fully compatible with TestNG.


The Clover-for-Maven 2 plugin allows you to produce Clover code coverage reports from the Maven 2 build tool. It provides detailed information to highlight areas of low coverage in your project, helping to guide your unit-testing activities.


Follow these simple steps to upgrade Clover for:


Clover can run the clean goal in Maven2 with the clover2:instrument goal at the same time.

There are two main choices when running the maven-clover2-plugin in a multi-module project:

1) use a database for each sub-module, and then run clover2:aggregate to merge all databases
2) specify the single Clover Database configuration parameter, which means only a single clover database will be used. clover2:aggregate is not required


You can exclude test code from being instrumented by Clover, however this will prevent Clover measuring per-test coverage. Test optimization will also not be available if tests are not instrumented.


Both. Clover's reports can be generated centrally, for the entire team, or individually, on a developer desktop. A common usage is to have Clover's Ant or Maven integration generating a HTML report from a regular Continuous Integration build. This report is then published to a team intranet. In conjunction, individual developers use Clover's IDE integrations to interactively measure coverage during their development activities.


Clover can faithfully measure coverage generated from any Java execution. To measure coverage from manual functional tests, instrument your application with Clover and then deploy as normal. Perform the functional tests, then generate a Clover report to see which code was executed.


Clover 2.4 will not interfere with the JetBrains/TeamCity test reordering feature. TeamCity uses a runtime inspection process that may add tests to the test run that Clover would not have chosen to run. This may result in longer running times.


All tests that failed in the previous test run will be run first, along with any new tests.


Clover uses a source file checksum to determine file modifications. There is no dependency on version control information.


Clover does not require access to any version control. It works via a local checkout or work area. Clover can happily be used in an environment that uses Accurev for version control.


Clover has two ways to speed up testing, which can be used together or separately. Optimization will select only a subset of tests that are applicable to the given set of changed source files. Test re-ordering will change the test execution order so as to encourage faster failure. Running a subset of tests will obviously be faster than running the full test suite. Test re-ordering will be faster because tests that failed previously, and tests that run faster, will be run first.


Clover supports Selenium RC testing. To get full per-test coverage and test optimization functionality, any server code being driven via selenium must be running in the same JVM as the Selenium RC JUnit tests.


Clover currently produces console output when optimization is occuring. The output includes the number of tests selected to run, the total number of candidate tests considered, and the estimated time saving.


Yes, you can use Bamboo's user-defined artifacts to pick up Clover reports, which will then be linked to your build.


Clover only supports Java at the moment.


The clover.snapshot file must exist between clean builds by default, this is stored in target/clover/clover.snapshot

The clover2:clean goal can be used instead of clean. This ensures everything else is cleaned except the snapshot file. Alternatively, you can specify an alternate snapshot location.


Optimization can be run directly, from the command line. It is not recommended to have optimization run by default however since this may mean "clovered" code get deployed accidently. Check out our Maven Best Practices.

To run optimization on the command line: mvn clover2:clean clover2:setup verify clover2:snapshot


  • No labels