CODEWITHSUNDEEP
sonarqubecode-coveragesonarqube-scan
Alix
Alix

Reputation: 2837

Coverage metrics do not consider code without tests?

In a project where some components have test coverage and others don't it seems that SonarQube only calculates the total code coverage based on the components that have coverage. I would expect that the lines of code in components without test coverage are classified (at least for calculations) as having 0% code coverage.

Example:

SonarQube coverage (Project X): 100%

How is the total coverage calculated? If this is by design, why?

Upvotes: 2

Views: 1541

Answers (1)

Gerald Mücke
Gerald Mücke

Reputation: 11132

Coverage is calculated based on the lines covered during test execution. If you have no test, test execution is skipped, no code is executed at all and therefore no coverage data is produced. So there is a difference between N/A and 0%

If you add an empty test to the module, it will be used for calculation and produce 0% coverage as result.

EDIT: Assuming you are using Jacoco for coverage. Jacoco write the coverage information into a file (i.e. jacoco.exec). For unit tests (maven surefire) this file is written to the target directory of the module and coverage is calculated for that module using that file. No file, no coverage.

When I run integration tests, I want to determine what parts of the code of the entire project is covered by a tests. My integration tests are typically located in separate module as well. So per-module coverage doesn't make much sense in that case, because test (1 module) and product (all other modules) are sparated. So I run the integration tests and write the coverage information into a single jacoco-it.exec file into the target folder of the root module (project). As a result, the coverage for the entire code base is calculated, including modules with 0% coverage (See here for how to set it up: Multi-Module Integration Test Coverage with Jacoco and Sonar)

What you loose with this approach is, what parts of code of a single module are covered by tests of that single module. Because parts of a module can be covered by tests of another module, i.e. coverage of a module can be 30% without having any test in that module.

So you have the choice:

  • detailed coverage per module, with test-less modules having N/A coverage
  • total coverage for entire project, with test-less modules having 0% coverage but without exact coverage information by module
  • both: using both approaches for unit test and integration tests separately

Upvotes: 3

Related Questions