9to5 coverage · Guides
Patch coverage vs project coverage
Understand why overall coverage can improve while a pull request still introduces untested code.
Two metrics answer different questions
| Metric | Question | 9to5 check |
|---|---|---|
| Project | How much of the uploaded codebase was executed? | At least the recorded baseline; neutral without one |
| Patch | Which relevant changed lines were executed? | 100% of relevant changed lines |
Imagine a baseline with 900 covered lines out of 1,000: 90% project coverage. Your PR covers 20 previously untested lines and introduces 10 relevant lines, but only 8 of those new lines are covered. Project coverage rises to 928 / 1,010 = 91.88%, while patch coverage is 8 / 10 = 80%.
Use the result to choose the next test
The project check can pass in that example because overall coverage improved. The patch check fails because two changed lines remain untested. Focus on those lines and their surrounding behavior before expanding unrelated coverage.
The reverse can happen too: all relevant changed lines are tested, while a changed test configuration removes coverage elsewhere. Read both checks and inspect the actual report and baseline.
Keep the measurement comparable
- Use the same report format and consistent source inclusion/exclusion rules.
- Verify paths line up with the PR checkout, especially after moving files or changing build directories.
- Inspect the persisted baseline: a latest-branch fallback is not necessarily the exact branch-start commit.
- Check files absent from reports. 9to5’s changed-line calculation only includes reported line records.
Coverage is an input to review
Execution is evidence that a path ran, not evidence that the assertions would catch a defect. Include negative cases and boundaries when the behavior requires them. A 100% patch result should support code review, not replace it.