Code Coverage Numbers

The best answer identifies:
1. The exact threshold breach (67.3% vs 80%)
2. The consequence (build blocked)
3. WHERE the gap is (auth module, not utils/api)
4. The risk context (security-critical files justify prioritising them)

Why this matters:
• `src/api/users.ts` at 94.1% is fine — no action needed
• `src/utils/hash.ts` at 88.7% is fine
• The problem is entirely within `src/auth/` — this is precisely where you WANT coverage because auth bugs = security vulnerabilities

Key vocabulary:
• code coverage — the percentage of code lines/branches executed by the test suite
• coverage threshold — the minimum coverage required to pass the build (configured in Jest, Pytest, etc.)
• block the build — prevent the CI pipeline from succeeding
• coverage gap — the difference between current coverage and the threshold
• security-critical — code where bugs would have security consequences

Common coverage tools: Jest (JS/TS), Istanbul/nyc (JS), pytest-cov (Python), JaCoCo (Java), SimpleCov (Ruby)

What makes option B correct:
• Specifies the drop in percentage points (not "percent")
• Calculates the actual ratio: 847 ÷ 120 ≈ 7:1 (untested lines per test line)
• Names the cause objectively ("shipping faster than writing tests") without blaming
• Avoids vague language ("very bad", "expected")

Key vocabulary:
• percentage points (pp) — absolute difference: 84.2% − 71.8% = 12.4 pp
• test debt / tech debt — deferred work that must be done later; here, untested code that creates risk
• test coverage ratio — informally: lines covered / lines added
• uncovered lines — lines of production code not executed by any test

Common causes of coverage drops:
• New feature code added without corresponding tests ("move fast" sprints)
• Complex new code that's harder to unit test
• Third-party integrations that are hard to mock
• Generated code (e.g. Prisma types, GraphQL) counted in total

Professional framing:
"Our coverage declined 12.4 pp this sprint. I'd suggest we budget 20% of next sprint's capacity to write tests for the auth and payment modules before they go to production."

The crucial distinction: coverage ≠ correctness

1. Execution vs. assertion:
A test that calls a function contributes to line coverage — but if it doesn't assert the result, it won't catch bugs.

Example:

test("processes payment", () => { processPayment(100, "USD"); /* no expect() */ });

This test gives 100% line coverage for `processPayment` but catches nothing.

2. Line coverage vs. branch coverage:
Line coverage = were these lines executed?
Branch coverage = was every possible `if/else/switch` path tested?

A function with:
`if (amount > 0) { charge(amount); } else { refund(); }`
…can be 100% line covered if only the `amount > 0` path is tested — but the `refund()` branch is never exercised.

Key vocabulary:
• line coverage — % of code lines executed by tests
• branch coverage — % of conditional branches (if/else, switch case) exercised
• statement coverage — similar to line coverage
• assertion — the `expect(result).toBe(expected)` check that validates behaviour
• false sense of security — high coverage that doesn't actually verify correctness

Practical advice: "Coverage is a floor, not a ceiling — useful for finding untested code, not for proving correctness."

Risk × coverage gap is the correct prioritisation framework.

Why option A fails:
Testing 0%-covered utility files may improve the number significantly, but if those utilities are low-risk (e.g., string formatters), you've improved the metric without reducing actual business risk.

Why option B is incomplete:
Complexity matters, but a complex file in a non-critical area is less important than a simpler file in the payment path.

Why option D is reactive:
Recent changes are worth testing, but "recent" alone ignores risk — a recent change to a debug log helper is lower priority than existing untested billing logic.

The matrix approach:
• High risk + low coverage → Priority 1 (billing, auth, data integrity)
• High risk + decent coverage → Priority 2 (improve edge case testing)
• Low risk + low coverage → Priority 3 (do eventually)
• Low risk + high coverage → Leave it

Key vocabulary:
• cyclomatic complexity — a measure of the number of independent paths through code; high complexity = more branches to test
• business-critical — functionality where failures have direct business or financial impact
• risk-based testing — prioritising test effort based on the probability and impact of failure
• coverage gap — distance between current coverage and the target threshold

Option C is the professional, constructive response — it demonstrates technical depth and collaborative problem-solving.

Why option C works:
1. Acknowledges the reviewer's concern
2. Commits to a concrete action (add unit tests for core logic)
3. Identifies a legitimate technical challenge (config readers → hard to unit test in isolation)
4. Proposes alternatives (integration tests / exclude from coverage) rather than just arguing
5. Asks a question rather than unilaterally deciding

This is significant because some code is legitimately hard to unit test:
• Config file readers (require file system or environment setup)
• Database migration scripts (require a live DB)
• Event handlers (require integration context)
• Thin wrappers around third-party SDKs

Key vocabulary:
• unit test — tests a single function/class in isolation with mocked dependencies
• integration test — tests multiple components working together (may include DB, filesystem, etc.)
• coverage exclusion — explicitly tell the coverage tool to ignore specific files (e.g., `/* istanbul ignore next */` in JS)
• blocking a PR — requesting changes that must be resolved before merge
• threshold — the minimum coverage % required to pass

Professional vocabulary for coverage discussions:
"Flag this", "address the concern", "bring coverage back up", "hard to unit test in isolation", "should this be excluded from reporting?"