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
SonarQube Scanner for Jenkins
Environment: Local Development
Eclipse Oxygen with EclEmma
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?