Test Coverage

Last modified by Vincent Massol on 2023/04/14 15:19

Code Coverage while running Maven tests

We now have a SonarQube instance showing Test coverage for both unit tests and integration tests. However it doesn't aggregate coverage data across top level modules (commons, rendering, platform, enterprise, etc).

We support both Jacoco and Clover to generate test coverage reports.

To generate test coverage reports make sure you can build your module and then pick one of the following strategies below depending on what you wish to generate.

Single Maven Reactor

Using Jacoco

  • Go in the first top level module (e.g. xwiki-commons, also works for extensions) and run: mvn clean jacoco:prepare-agent install -Djacoco.destFile=/tmp/jacoco.exec -Djacoco.append=false -Plegacy,integration-tests -Dxwiki.revapi.skip=true -Dmaven.test.failure.ignore=true
  • Go in all the other top level modules you wish to add and run: mvn clean jacoco:prepare-agent install -Djacoco.destFile=/tmp/jacoco.exec -Djacoco.append=true -Plegacy,integration-tests  -Dxwiki.revapi.skip=true -Dmaven.test.failure.ignore=true
  • Then whenever you wish to generate the full test report, run: mvn jacoco:report -Djacoco.dataFile=/tmp/jacoco.exec


    Jacoco supports generating report from a single module, it even supports generating aggregated report from several modules using the report-aggregate mojo introduced in 0.7.7 (but note that I don't know if that includes coverage induced by module B on module A). However jacoco doesn't seem to support the ability to execute several maven reactors (for example for building code located in various github repositories), using the same jacoco exec file and then generate a report for that. See also https://groups.google.com/forum/#!topic/jacoco/odVzr7P5i6w

Using Clover

Go to the top level module containing children modules for which to generate a Clover report. Note that you won't be able to aggregate Clover data across different Maven runs with this strategy so you really need a single parent module.

  1. Run the following command (adjust the local repo path):
    mvn clean clover:setup install clover:aggregate clover:clover -Pclover,integration-tests,dev,jetty,hsqldb,docker -Dxwiki.revapi.skip=true -Dmaven.repo.local=/Users/vmassol/.m2/repository-clover -Dmaven.test.failure.ignore=true -nsu
    • You might need to run the "install" goal instead of the "test" one if your local Maven repository doesn't already contain some test jars (apparently and for some reason Maven won't download them from the remote repository under some conditions).
    • Note that we use -Dmaven.repo.local to use a different Maven local repository so that instrumented source code and built binaries don't find their way in your standard local repository (which you could then deploy by mistake, or that'll simply fail your tests later on when you don't run with the Clover profile since instrumented artifacts require the Clover JAR to be present in the classpath at runtime...).

Multiple Maven Reactors

Using Jacoco


Using Clover

Use a single Clover database to which you add coverage information as you build modules one after another. This strategy is especially useful when you wish to manually run some modules and ensure that coverage data aggregate in a single place so that when you generate the report you have the result of all your runs.

  1. Instrument the source code with Clover for all modules that you want to include in the report, using (adjust the paths):
    mvn clover:setup install -Pclover,integration-tests,dev,jetty,hsqldb -Dmaven.clover.cloverDatabase=/Users/vmassol/.xwiki/clover/clover.db -Dxwiki.revapi.skip=true -Dmaven.repo.local=/Users/vmassol/.m2/repository-clover -nsu

    When tests are executed they'll generate coverage data in the specified Clover database. Since there's a single Clover there's no need to merge Clover databases as in strategy 1 above.

  2. To generate the Clover report, execute the following from any module (adjust path):
    mvn clover:clover -N -Dmaven.clover.cloverDatabase=/Users/vmassol/.xwiki/clover/clover.db -Dmaven.repo.local=/Users/vmassol/.m2/repository-clover -nsu
  3. Remember to clean your clover database when you're done.

If you don't wish failing tests to stop the generation of the coverage report, you should pass -Dmaven.test.failure.ignore=true on the command line.

Here are typical steps you'd follow to generate full TPC for XWiki:

  • Clean your local repo and remove any previous clover DBs:
    rm -R ~/.m2/repository-clover/org/xwiki
    rm -R ~/.m2/repository-clover/com/xpn
    rm -R ~/.xwiki/clover
  • Generate coverage data for XWiki Commons:
    cd xwiki-commons
    mvn clean -Pclover,integration-tests -Dmaven.repo.local=/Users/vmassol/.m2/repository-clover -nsu
    mvn clover:setup install -Pclover,integration-tests -Dmaven.clover.cloverDatabase=/Users/vmassol/.xwiki/clover/clover.db -Dmaven.repo.local=/Users/vmassol/.m2/repository-clover -Dmaven.test.failure.ignore=true  -Dxwiki.revapi.skip=true -nsu
  • Generate Clover report just for Commons:
    mvn clover:clover -N -Dmaven.clover.cloverDatabase=/Users/vmassol/.xwiki/clover/clover.db -Dmaven.repo.local=/Users/vmassol/.m2/repository-clover -nsu
  • Generate coverage data for XWiki Rendering:
    cd xwiki-rendering
    mvn clean -Pclover,integration-tests -Dmaven.repo.local=/Users/vmassol/.m2/repository-clover -nsu
    mvn clover:setup install -Pclover,integration-tests -Dmaven.clover.cloverDatabase=/Users/vmassol/.xwiki/clover/clover.db -Dmaven.repo.local=/Users/vmassol/.m2/repository-clover -Dmaven.test.failure.ignore=true  -Dxwiki.revapi.skip=true -nsu
  • Generate Clover report for Commons and Rendering:
    mvn clover:clover -N -Dmaven.clover.cloverDatabase=/Users/vmassol/.xwiki/clover/clover.db -Dmaven.repo.local=/Users/vmassol/.m2/repository-clover -nsu
  • Generate coverage data for XWiki Platform:
    cd xwiki-platform
    mvn clean -Pclover,integration-tests -Dmaven.repo.local=/Users/vmassol/.m2/repository-clover -nsu
    mvn clover:setup install -Pclover,integration-tests -Dmaven.clover.cloverDatabase=/Users/vmassol/.xwiki/clover/clover.db -Dmaven.repo.local=/Users/vmassol/.m2/repository-clover -Dmaven.test.failure.ignore=true  -Dxwiki.revapi.skip=true -nsu
  • Generate full Clover report (for Commons, Rendering and Platform):
    mvn clover:clover -N -Dmaven.clover.cloverDatabase=/Users/vmassol/.xwiki/clover/clover.db -Dmaven.repo.local=/Users/vmassol/.m2/repository-clover -nsu

Using Clover + Jenkins

  • Install Jenkins LTS and the following plugins:
    • Pipeline plugin
    • Docker Cloud Plugin
  • Setup Jenkins to spawn Docker agents using the XWiki Build image.
  • Setup a Global Pipeline Library in Jenkins that points to https://github.com/xwiki/xwiki-jenkins-pipeline (make sure it's loaded implicitly).
  • Setup a Jenkins Clover pipeline job with a script such as:
    node('docker') {
           [baseline: "20171222-1835", fail: false],
           [baseline: "20190106-0207", fail: false],
           [baseline: "latest", fail: true]
  • You can check the code for the xwikiClover step.
  • Check the results.

Note that the Clover pipeline script will generate a report with differences from the previous passing report showing the contributions (positive and negative) of each module to the global TPC.

Example Reports

Code Coverage on a live XWiki instance

Using JaCoCo

JaCoCo comes with the EclEmma Eclipse plugin which probably provides a more user-friendly / integrated way to get code coverage if you use Eclipse. If you use Eclipse, you may want to look into it, and document how to use the EclEmma here. Here, we describe how to use JaCoCo using the command line.

We will assume you use a POSIX shell (bash, zsh... likely the case if you run GNU/Linux, macOS or WSL.  Other users, including people using Powershell or CMD on Windows, will need to adapt the steps to make them work on their setup).

You can run any Java program and check its code coverage as it runs. That includes XWiki.

Download JaCoCo from https://www.jacoco.org/jacoco/ and extract it wherever convenient. In the reminder of this section, we will assume it is extracted at $JACOCO_PATH. You can set this variable like this (in every terminal session you will use) if you want to copy paste from this doc.


JaCoCo has two parts that concerns us:

  • A Java agent, running with the program of which you want to cover the code. Java agents are specified with their options when running the program with the java command.
  • A command line tool that will speak to this agent and generate reports

First, run XWiki with the agent. We fully recommand you to read the JaCoCo agent documentation. We will assume you use the demo package downloaded from Download or XTool. If you run XWiki differently, adapt in consequence.

With the demo package, XWiki is started using start_xwiki.sh (or start_xwiki_debug.sh), and XTool uses it too. You can pass options to Java using the XWIKI_OPTS environment variable, which defaults to -Xmx1024m if you don't set it. Will specify the agent using this environment variable.

Using start_xwiki.sh:

XWIKI_OPTS="-Xmx1024m -javaagent:$JACOCO_PATH=destfile=/tmp/jacoco.exec,append=false,output=tcpserver" ./start_xwiki.sh

Or using XTool:

XWIKI_OPTS="-Xmx1024m -javaagent:$JACOCO_PATH=destfile=/tmp/jacoco.exec,append=false,output=tcpserver" x start myinstance

This means that XWiki will be run with JaCoCo producing its data file at /tmp/jacoco.exec, listening for orders on TCP port 6300 as instructed by the output=tcpserver. If you wonder where this 6300 comes from, please read its docĀ :-). This has security consequences, you can also choose that you don't want to enable the TCP listening. Then JaCoCo will dump its analysis to /tmp/jacoco.exec when you stop XWiki.

It is fully expected that the JaCoCo exec file (here /tmp/jacoco.exec) is present as soon as XWiki starts but empty until JaCoCo dumps its analysis. Which happens when we ask it to, or, if you didn't provide the output parameter, at the end of XWiki's execution.

if you want to keep JaCoCo's analysis accross reboots for later report generation, or if you are low on space in /tmp, which can happen if /tmp is a tmpfs (in RAM) and you don't have a lot of it, pick another location.

Then, when you want to see the report, use JaCoCo's command line tool ask JaCoCo to dump its analysis and then to produce an HTML report. See JaCoCo's cli documentation.

Dump the analysis:

java -jar "$JACOCO_PATH/lib/jacococli.jar" dump --destfile /tmp/jacoco.exec

Produce the report:

mkdir -p "$HOME/jacocohtml" # you can pick another location
java -jar "$JACOCO_PATH/lib/jacococli.jar" report /tmp/jacoco.exec --classfiles=$HOME/.xtool/instances/myinstance/data/extension/repository/ --sourcefiles /path/to/your-source-code/src/main/java/ --html "$HOME/jacocohtml"

JaCoCo needs your class files and the path to your source code. Here we provide an example where we are using XTool and we named our XWiki instance myinstance. Change this path to point to the right data/extension/repository directory. If you (also) want to analyse classes provided with XWiki, try to provide the path to WEB-INF/lib (I did not try this). you can provide several paths by using a colon separator (:)

java -jar "$JACOCO_PATH/lib/jacococli.jar" report /tmp/jacoco.exec --classfiles=$HOME/.xtool/instances/myinstance/data/extension/repository/:$HOME/.xtool/instances/myinstance/webapps/xwiki/WEB-INF/lib/ --sourcefiles /path/to/your-source-code/src/main/java/:/path/to/xwiki-source-code/xwiki-platform/xwiki-platform-xxx/xxx/src/main/java/ --html "$HOME/jacocohtml"

Get Connected