FAQs

This page contains answers to common questions and things to keep in mind when using the Diffblue SonarQube Plugin.

Frequently Asked Questions (FAQs)

Why do the Diffblue metrics not exactly match up with SonarQube’s Coverage metrics?

There can be slight discrepancies between SonarQube’s measures and the Diffblue SonarQube metrics. This is due to differences in how SonarQube, JaCoCo, and the Diffblue SonarQube Plugin define the following terms.

SonarQube
Diffblue SonarQube Plugin

Coverable lines

Lines to cover. This is the number of lines of code that could be covered by unit tests. For example, blank lines or full comments lines are not considered as lines to cover.

If SonarQube's xmlReportPaths property is configured to use Diffblue's JaCoCo XML reports, this number will match the Diffblue SonarQube Plugin's Coverable Lines measure. If the property is not set or is set to other reports, there may be a slight difference.

A line is counted as coverable if, for a line in a class in the JaCoCo coverage reports, ci + mi > 0 . That is, if the line contains at least 1 bytecode instruction.

Coverage

Line coverage.

coverage = lines where at least one instruction is covered / coverable lines

This is based on JaCoCo’s documentation: https://www.eclemma.org/jacoco/trunk/doc/counters.htmlarrow-up-right

Line coverage

Has this line of code been executed during the execution of the unit tests?

See https://docs.sonarsource.com/sonarqube-server/user-guide/code-metrics/metrics-definition#coveragearrow-up-right for the equation used.

The Diffblue SonarQube Plugin doesn't distinguish between coverage and line coverage. Our measure of coverage is line-based as described above.

Generated code is another potential source of discrepancies between metrics. It is best practice to exclude generated code from coverage analysis. Diffblue Cover will warn if it detects that coverage was measured for generated code; see Environment Codes - E165 for how to configure JaCoCo to exclude generated code. See SonarQube's documentation for how to exclude generated code from SonarQube analysis.

How does coverage highlighting work when using the Diffblue SonarQube Plugin?

While SonarQube will perform static analysis to determine Lines to Cover in the absence of coverage files, SonarQube's coverage highlighting in the UI will only work if coverage files are provided. If it cannot find coverage files, all lines will be shown as uncovered. Diffblue Cover's coverage-reports command writes files to specific location which differs from the standard location.

To align SonarQube's coverage highlighting in the UI and the Lines to Cover measure with Diffblue's measures, configure your project to use the Diffblue-generated JaCoCo XML files using SonarQube's sonar.coverage.jacoco.xmlReportPaths property. The line coverage highlighting will then reflect lines covered by all Diffblue and manual tests. This can be done in several ways.

Set in the SonarQube UI

Go to Project Settings > General Settings. In the JaCoCo section, add an entry for each report: .diffblue/reports/diffblue-tests-jacoco-report.xml and .diffblue/reports/manual-tests-jacoco-report.xml . The order does not matter. These patterns will be used for each module in the project.

Within your project

The property can be set in your Maven or Gradle build files. For example, in a Maven project, you can set the below in the parent pom.xml , or in each module's pom.xml :

<properties>
    <sonar.coverage.jacoco.xmlReportPaths>
        .diffblue/reports/diffblue-tests-jacoco-report.xml,
        .diffblue/reports/manual-tests-jacoco-report.xml
    </sonar.coverage.jacoco.xmlReportPaths>
</properties>

In a Gradle project, add the below to the build.gradle :

Passed in the SonarQube CI command

For a Maven or Gradle project, add the below property to the SonarQube command run in CI:

Last updated

Was this helpful?