Code coverage is covered to 0% when I skip tests using -DskipTests and -Djacoco.skip=true

My app’s Code coverage is correctly collected after I collectly config all things.
But I need to skip tests in some scene because it costs too much time if all tests run completely.So I add some params when I run ‘mvn clean install sonar:sonar’ like -DskipTests and -Djacoco.skip=true.The logs show the tests and jacoco is all skiped correctly,but when it finished, the app’s coverage is covered to 0% on SonarQube.

The Question is how can I ensure the code coverage won’t be covered to 0% when I skip tests and jacoco?

I wondered caused this problem, but this param has been Deprecated.



Welcome to the community!

The thing is, if you skip tests in your build, then SonarQube has 0 information about coverage, and all it can report is 0% coverage.

Maybe you want to run a job overnight that executes all your tests and correctly reports coverage to SonarQube?


Thanks for your reply.
I hope the SonarQube show the last coverage rate when I skip all tests and skip jacoco,instead of replaced to 0%.
Can we do some settings to reach this target?

My team need to see the real coverage rate all the time, and it costs too much time if we run all the tests everytime we build and deploy our app.
So we add -DskipTests and -Djacoco.skip=true when we run ‘mvn clean install’.

I hope it’s clear by now, you can’t get something for nothing. The SonarQube scan represents the results from the latest scan. If you don’t run tests in a build that you run a scan on, you won’t get test coverage. Test coverage is defined as the coverage you achieve by the running of your unit tests. It would not make any sense for the scan to use the “last coverage rate” if it can’t find any coverage information.

I would suggest that, if your unit tests are taking too long, they likely aren’t very good unit tests. Unit tests are intended to just test the business logic of your code. They should not make external connections, and they shouldn’t start up complex containers to run unit tests. For instance, many developers often make the mistake of running a Spring container to run ordinary unit tests, when the vast majority of the time, it simply doesn’t need it.


This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.