We have a maven multi-module project with a reported code coverage difference between Eclipse and SonarQube.
Some of the difference is understood, based on the differences in how SonarQube and EclEmma count instructions. I don’t believe this is the issue.
In this case, there are entire classes which are shown as covered in Eclipse, but are not shown as covered in SonarQube.
Environment: Build Server
Jenkins 2 - build initiated in pipeline in a withSonarEnv step, using mvn sonar:sonar
SonarQube 6.7.1
SonarQube Scanner for Jenkins
sonar-maven-plugin:3.4.0.905
SonarJava 4.15.0.12310
jacoco 0.8.0
Environment: Local Development
Eclipse Oxygen with EclEmma
Scenario
The Maven project contains modules “api”, “service” and “dao”
A broad stack test initiated at the api layer covers code in the service and dao layers (as indicated by Eclipse EclEmma).
A specific class in the service layer that was covered via EclEmma does not show as covered in SonarQube.
I see from the jacoco.exec file that the service class is included and is covered (8 out of 8 probes are covered)
From looking at the SonarJava source code, it appears the class is not on the analysis classpath, and is therefore ignored.
I’ve read the documentation and don’t believe this situation is addressed. Our organization is moving toward a Test Pyramid orientation, in which case this scenario would likely go unnoticed because the service class (in this example) would be covered by a unit test. But until then, I need to configure the Build server to report proper code coverage for broad stack tests.
My question: is the above scenario supported by SonarQube? If so, could you please point me to documentation on how to add the service and dao modules to the analysis classpath?
to me seems that not counting Gradle it describes exactly your case where tests in one module cover classes in another module.
EclEmma itself is structured like that and uses Maven - e.g. tests in module org.eclipse.eclemma.core.test cover classes in module org.eclipse.eclemma.core. And EclEmma is configured as described in mentioned above post:
Most common trick to cross boundaries - is to collect all coverage information into single location.
This allows to see combined coverage even in case when both modules have tests.
SonarQube 6.2 with Java Plugin 4.4 supports property sonar.jacoco.reportPaths allowing to specify multiple locations.
This also allows to see combined coverage even in case when both modules have tests.
For the completeness of picture should be mentioned that JaCoCo itself structured exactly like EclEmma and also uses Maven - tests in module org.jacoco.core.test cover classes in module org.jacoco.core, however configured differently:
such configuration also allows to see coverage produced by tests in org.jacoco.core.tests in SonarQube - https://sonarcloud.io/dashboard?id=org.jacoco%3Aorg.jacoco.build , however if one day org.jacoco.core will contain tests, then coverage produced by them won’t be shown in SonarQube.
Thank you for your detailed response. Much appreciated.
I just confirmed with the project team that this configuration change fixed the issue. SonarQube is now reading from a single jacoco.exec file and is showing code coverage on classes in the service and dao modules.