# HG changeset patch # User Dirk Olmes # Date 1589265022 -7200 # Node ID 6aa2fa328a94cbdfb2034ecd70f58715d43716e0 # Parent 94bbe517a17493bb38349db172c8b0c49ffcb5d6 New blog post on sonar and maven diff -r 94bbe517a174 -r 6aa2fa328a94 content/Maven/sonar-vs-jacoco-vs-surefire.md --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/content/Maven/sonar-vs-jacoco-vs-surefire.md Tue May 12 08:30:22 2020 +0200 @@ -0,0 +1,67 @@ +Title: Generating test coverage for Sonar with maven, surefire and jacoco +Date: 2020-05-11 +Lang: en + +At work we're using [Sonar](https://www.sonarqube.org) to keep our code quality under control. One integral part of code quality is test coverage and Sonar offers coverage metrics in the UI. However, the [Sonar docs on code coverage](https://docs.sonarqube.org/latest/analysis/coverage/) are a bit sparse (at best) and don't tell you the exact steps to run for getting coverage with a Maven build. + +With a bit of googling I was eventually able to find the correct steps to get coverage. The key to success is the [Jacoco Maven plugin](https://www.eclemma.org/jacoco/trunk/doc/maven.html). In a first Maven execution we let jacoco record coverage statistics while running the unit tests: + + :::bash + mvn clean org.jacoco:jacoco-maven-plugin:prepare-agent install + +In the build log you see the jacoco-maven-plugin in action (we'll get back to this in a while): + + [INFO] --- jacoco-maven-plugin:0.8.5:prepare-agent (default-cli) @ sonar-code-coverage --- + [INFO] argLine set to -javaagent:/.m2/repository/org/jacoco/org.jacoco.agent/0.8.5/org.jacoco.agent-0.8.5-runtime.jar=destfile=/sonar-code-coverage/target/jacoco.exec + +Then in a second Maven execution we'll pick up those coverage statistics and convert them to XML so that Sonar can include them in its analysis: + + :::bash + mvn org.jacoco:jacoco-maven-plugin:report org.sonarsource.scanner.maven:sonar-maven-plugin:sonar + +**Hooray! Coverage info in Sonar.** + +The trouble starts when you need to pass custom arguments through surefire down to the JVM that will run the tests. This is done through the `` configuration parameter of maven-surefire-plugin: + + :::xml + + org.apache.maven.plugins + maven-surefire-plugin + + -Xmx128m + + + +Looking back at the output of jacoco-maven-plugin above you'll notice that we're setting exactly the same `` parameter as jacoco-maven-plugin does. If you don't take extra steps only one configuration can win - and that's the configuration you put into your pom. You have to run `mvn -X` to actually see this, though: + + [DEBUG] Forking command line: /bin/sh -c cd /sonar-code-coverage && /opt/openjdk-bin-8.252_p09/jre/bin/java -Xmx128m -jar /sonar-code-coverage/target/surefire/surefirebooter9099169912642065145.jar /sonar-code-coverage/target/surefire 2020-05-12T07-39-04_225-jvmRun1 surefire3709014631518520641tmp surefire_01706858247537265191tmp + +Note how the `-javaagent:...` argLine is not included in the command line arguments of the JVM that's forked to run the tests. + +A way to fix this is through creative use of Maven build properties. Configure the jacoco-maven-plugin to set a different property than `argLine`: + + :::xml + + org.jacoco + jacoco-maven-plugin + + surefire.argLine.sonar + + + +Next, configure maven-surefire-plugin to include that property into its ``: + + :::xml + + org.apache.maven.plugins + maven-surefire-plugin + + -Xmx128m @{surefire.argLine.sonar} + + + +Note that you have to use [late evaluation](http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#argLine) of the property because it's not present when the Maven reactor starts but only after jacoco-maven-plugin has run. + +Just one last hack is required to make the build work even if you don't run jacoco coverage as part of your build. Specify an empty property `surefire.argLine.sonar` in your project's properties so that it always exists and can be expanded. + +For further reference I've put [a demo project up on github](https://github.com/dirk-olmes/sonar-code-coverage).