Notifications
Clear all
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.
NHIMG editorial — based on content published by Sonar: SonarQube coverage failures usually stem from pipeline handoffs
Questions worth separating out
Q: How should teams troubleshoot 0% code coverage in SonarQube?
A: Start at the pipeline, not the dashboard.
Q: Why do SonarQube coverage numbers differ from pytest or JaCoCo?
A: They often count different things.
Q: What do security teams get wrong about coverage as a control signal?
A: They treat coverage as proof that code is well tested.
Practitioner guidance
- Validate the coverage handoff chain Check that tests run, a coverage report is written, the report format matches the language, and the scanner points to the correct file before you inspect the dashboard.
- Remove silent failure paths Audit scanner properties for deprecated names, confirm the analysis mode supports coverage import, and fail the pipeline when the report file is missing or unreadable.
- Standardise path handling in CI Use relative file paths that match the scanner’s project view, and fix monorepo or container path mismatches with language-specific settings such as relative_files where appropriate.
What's in the full article
Sonar's full article covers the operational debugging detail this post intentionally leaves at a higher level:
- Language-specific report paths and file locations for Java, JavaScript, Python, C#, and Go builds
- Exact scanner property names that replace deprecated settings and prevent silent import failures
- Debug-log checks that show whether the report was found, parsed, or skipped during analysis
- CI ordering examples that show how to ensure the scanner runs only after coverage output exists
👉 Read Sonar's explanation of why SonarQube coverage reports fail →
SonarQube coverage gaps: where do CI pipelines usually fail?
Explore further
19/08/2026 4:31 pm
Coverage integrity is a governance problem, not just a developer inconvenience. The article shows that a passing test suite can still produce 0% or misleadingly low coverage if the report handoff fails. That is the same control pattern identity teams see when telemetry is present but not trustworthy. The practitioner lesson is to treat build-time assurance data as a governed control surface, not a side effect of tooling.
A question worth separating out:
Q: How do you know when coverage failures are caused by CI configuration?
A: When the tests pass but the report is missing, the report is in the wrong format, or the scanner runs before the report is created, the issue is almost certainly CI configuration. That is where teams should look first, especially in containerised builds and parallel jobs.
👉 Read our full editorial: SonarQube coverage failures usually stem from pipeline handoffs
