Clover 2.4 webinar questions

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

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

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

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.