Test coverage
What it is
Test coverage measures how much of the source code is exercised by the automated test suite — commonly reported as a percentage of lines or branches executed during the run. CI collects this at test time and publishes it (Azure Pipelines PublishCodeCoverageResults; GitHub adapters like JaCoCo/Jest) so the graph and PR can show the coverage trend per change.
Why it exists
Coverage is a cheap, continuous quality-risk indicator: low coverage means new code is untested, so defects are more likely to escape to production. By gating on a coverage floor, teams turn CI into a guardrail that blocks merges that would erode test coverage — complementing (not replacing) meaningful assertions.
Key ideas
- Line vs branch coverage: line = statements executed; branch (MC/DC) = whether each conditional’s paths are taken — branch is stricter.
- Coverage ≠ behavior: 100% coverage can still hide bugs — pair it with good assertions and tests.
- Publishing: test tasks attach coverage artifacts to the run; these feed the quality gate and the diff report.
- Gates: a threshold (e.g. ≥80%) fails a run/job when breached, blocking the PR/merge.
How it fits (diagram)
Exam notes
- The exam distinguishes line coverage from branch coverage and that coverage is a trend/gate, not proof of correctness.
- Coverage results are published as artifacts on the run — usable downstream and visible in the review.
- A coverage gate is a classic CI quality-gate answer to “how do we stop untested code?”
Related
pipeline-run · build-artifact · pipeline-evaluation-and-quality-gates · azure-pipelines
📘 Source: Publish code coverage results task · Publish test results task