Topic starter
19/08/2026 3:55 pm
TL;DR: Most 0% coverage results come from handoff failures such as missing reports, wrong formats, deprecated properties, or CI timing, according to Sonar. The broader lesson is that coverage is a pipeline integrity problem, and AI-generated tests can still pass while verifying nothing.
Editorial analysis by NHI Mgmt Group, based on content published by Sonar: “How SonarQube code coverage reporting works”.
Key questions
Q: Why does SonarQube show 0% coverage when tests pass?
A: Because the scanner only reports what it can find in a valid coverage report.
Q: What is the difference between SonarQube coverage and language tool coverage?
A: Different tools count different executable units.
Q: How do teams know whether coverage is failing because of configuration or code?
A: Start with the report file, the scanner property, and the scanner run order.
Practitioner guidance
- Validate the coverage artifact before analysis Check that the coverage report exists after the test step and before sonar-scanner runs, then confirm the file format matches the language-specific expectation.
- Replace deprecated scanner properties Review sonar-project.properties and CI flags for old coverage keys such as deprecated report path names, then update them to the current property names.
- Align report paths with the repository layout Make sure report paths are relative to the scanner working directory and that monorepo or module-relative paths resolve to the same source tree SonarQube sees.
Bottom line: SonarQube coverage failures usually come from broken pipeline handoffs, not from the coverage dashboard itself.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:31 pm
Coverage handoff integrity is the real control problem: Sonar’s analysis shows that coverage is not a single metric but a chain of dependencies across test execution, report generation, scanner configuration, and source-path resolution. When teams focus only on the dashboard, they miss the operational point where the signal is lost. Practitioners should govern coverage as an evidence pipeline, not a vanity metric.
A question worth separating out:
Q: What should engineers check when coverage is lower than expected after a CI change?
A: Check for deprecated property names, changed report paths, altered working directories, and container path differences introduced by the new pipeline. CI changes often break the evidence chain without changing the tests themselves, so the first task is to confirm the scanner still sees the same report in the same place.
👉 Read our full editorial: SonarQube coverage failures usually stem from pipeline handoffs