Skip to end of metadata
Go to start of metadata

Code Coverage

RHQ uses Jacoco for test code coverage.

Per module

In each module, you can run

which will produce a code coverage report in:

Those locations contain a CSV (jacoco.csv), XML (jacoco.xml) and HTML (index.html) reports of the test code coverage for given module.

The great thing about the HTML report is that you can drill down to source code and see what individual lines in your source code are covered by tests and what aren't.

Overall report

If you run with -Dcode-coverage from the root of RHQ source, you'll get an overall report from all the modules, located in:

That overall report is split by "functional areas": Core, GUI, Enterprise, Plugins and Miscellaneous. Again you can drill down to individual source files in these reports.

Testing recommendations

I recommend running code coverage before you commit anything (just in the modules you were working on) to see how much of the code that you've changed you were able to cover with unit tests - sometimes I find the results surprising, yet, of course, correct.

You can still limit the number of tests you run using the -Dtest=... and see the code coverage only for those tests. This will reduce the time you spend running the test builds yet will still give you the idea about the coverage generated by those tests.

Arquillian integration

This is not yet done and is pending the acceptance of our pull request. A prototype of the integration (once that pull request is released) is located in our codebase in this branch.

Implementation details

Jacoco runs as a Java agent during the test phase and is doing a runtime code enhancements to the classes to collect the coverage data. This is great because no special compilation phase needs to happen (unlike with other code coverage tools). The caveat for that is that we need to specify the java agent on the commandline of the java process running the tests.

In a simple case, this is done automagically. Surefire (or failsafe) plugins understand an argLine property that they use as the commandline arguments for the Java process running the tests. Jacoco plugin sets this variable by default in its "prepare-agent" goal.
In the case of RHQ, this is of course more complicated. We do set the argLine property on a couple of places for our own purposes - setting up sigar, java.library.path, running the tests with security manager, etc. To "push" the definitions for the Jacoco's java agent through to these definitions, you need to prepend all other definitions in the argLine by ${jacoco.unit-test.args} in case of unit tests or ${jacoco.integration-test.args} in case of integration tests like for example:

The code coverage itself is triggered by the code-coverage system property (as mentioned above). The reason for that is that we need a pair of mutually exclusive profiles to trigger (or not) the code coverage. Both of these are defined in the root pom and are called code-coverage and no-code-coverage. The no-code-coverage defines the above mentioned properties (jacoco.*.args) to empty strings so that they don't invalidate the argLine's of our tests, while the code-coverage profile sets up all the stuff required for running 2 individual coverage reports (one for unit and one for integration tests) and a merger of them (the overall report). Through inheritance these profiles are available in each module and therefore you can run code coverage in the same way in each module.

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.