Coverage, Test Execution Data, Duplication, and External Analyzer Reports: Core Concepts and Mental Model

1. The practical problem: evidence exists, but SonarQube cannot use what it cannot see

Chapter 13 interpreted measures after they already existed. Chapter 14 moves one step upstream: where coverage, test execution, duplication, and third-party findings come from. The most common beginner mistake is to treat SonarQube as a test runner or omniscient artifact collector. It is neither.

Your build/test/analyzer tool runs first. It creates an artifact in a particular format at a particular path. The scanner must then be told how to import that artifact—or use a documented default—and the scanner process must be able to see that path from its own workspace. Only imported evidence becomes part of the analysis report that the server processes.

2. Keep five evidence families separate

3. Coverage is external test evidence, not a Sonar test run

For Python, current Community Build consumes Cobertura-style XML through sonar.python.coverage.reportPaths. The report can be created by coverage.py directly or by pytest-cov. SonarQube does not invoke pytest for you.

python -m pytest --cov=src --cov-report=xml:reports/coverage.xml
# then, later:
sonar-scanner -Dsonar.python.coverage.reportPaths=reports/coverage.xml

Those two commands modify different state. The first changes producer evidence on disk. The second reads that evidence and changes scanner report/server analysis state. If the report is generated after sonar-scanner finishes, that analysis cannot retroactively acquire it.

4. Test execution data answers different questions

Coverage asks “which code was exercised?” Test execution asks “which tests ran and what happened?” Current Python analysis can import an xUnit-style report through sonar.python.xunit.reportPath; all-language Generic test execution uses sonar.testExecutionReportPaths.

5. A path is part of the evidence contract

When a scanner property accepts a report path, the scanner resolves it in its own filesystem context, normally relative to sonar.projectBaseDir. A path that exists on the Docker host may not exist inside a scanner container; a path from one CI job may not exist in another job unless the artifact was passed between them.

Record the producer working directory, scanner project base directory, report path, file size/hash, and execution order. That is far more useful than “coverage missing.”

6. Duplication is scanner/analyzer evidence, not imported coverage evidence

Current SonarQube metric definitions calculate duplicated_lines_density = duplicated_lines / lines × 100. For non-Java languages, duplicate blocks generally require at least 100 successive duplicated tokens and—outside COBOL/ABAP—at least 10 lines. Java uses 10 successive duplicated statements.

Therefore a tiny two-line repeated helper may correctly produce 0% duplication. Diagnosis starts with indexed files, supported language, CPD logs, thresholds, and sonar.cpd.exclusions—not with searching for a missing duplication XML file.

7. External issues extend visibility without becoming native Sonar rules

Supported external analyzers can use dedicated properties such as Python Pylint, Bandit, Flake8, Mypy, or Ruff report paths. Unsupported tools can produce SonarQube generic external-issue format or SARIF 2.1.0. For generic/SARIF imports, the external rules do not appear in SonarQube quality profiles; rule configuration remains in the producer.

This distinction matters operationally. A native issue can be traced to an active Sonar rule/profile. An external issue must also retain producer/tool version, external rule identifier, and report provenance.

8. Read-only inspection before changing anything

pwd
git rev-parse HEAD
sonar-scanner --version
python --version
python -m pytest --version
python -m coverage --version || true

find reports -maxdepth 1 -type f -print -exec wc -c {} \;
sha256sum reports/* 2>/dev/null || true

grep -E '^(sonar\.(projectBaseDir|sources|tests|python\.coverage\.reportPaths|python\.xunit\.reportPath|coverageReportPaths|testExecutionReportPaths|sarifReportPaths|externalIssuesReportPaths|cpd\.exclusions|coverage\.exclusions))=' sonar-project.properties 2>/dev/null || true

Only after the artifact exists and its path/format is known should you change an import property.

Knowledge check

Official references and version notes

• Test coverage overview — SonarQube consumes coverage reports generated by external build/test tools; it does not execute tests.
• Test coverage parameters — language-specific and generic coverage import keys including sonar.python.coverage.reportPaths and sonar.coverageReportPaths.
• Test execution parameters — execution-report keys including sonar.testExecutionReportPaths and sonar.python.xunit.reportPath; execution reports are branch-only.
• Generic test data — generic coverage and execution XML formats when a producer has no native integration.
• About external issues — supported external-analyzer integrations and how imported results participate in analysis.
• External analyzer reports — analyzer-specific report paths including Python Pylint/Bandit/Flake8/Mypy/Ruff integrations.
• Generic external-issue format — sonar.externalIssuesReportPaths and ownership semantics for third-party rules.
• SARIF reports — SARIF 2.1.0 requirements and sonar.sarifReportPaths.
• Scanner-only parameters — external report paths, report-task.txt, quality-gate wait behavior, and path resolution.
• Metric definitions — coverage/test metrics and current duplication/CPD thresholds and keys.
• SonarQube downloads — current Community Build release identity.
• SonarScanner CLI 8.1.0.6389 — standalone scanner baseline used in the local lab.