5 exercises — read coverage reports accurately, discuss coverage drops, understand line vs branch coverage, and communicate about test debt in professional English.
Coverage quick reference
Line coverage — % of code lines executed by tests
Branch coverage — % of if/else paths exercised
Coverage threshold — minimum % required for the build to pass
Test debt — untested code that accumulates over time
Coverage ≠ correctness — high % doesn't prove the code works correctly
How would you summarise this for a pull request comment?
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)
2 / 10
A QA engineer presents this sprint-over-sprint comparison:
Sprint 38: 84.2% overall | Sprint 39: 71.8% overall Uncovered lines added this sprint: 847 New test lines added: 120
How would you describe this trend professionally?
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."
3 / 10
A developer explains to a junior teammate:
"We have 91% line coverage, but we had a production bug in the payment module anyway. How is that possible?"
Which explanation is most accurate?
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.
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."
4 / 10
At a sprint planning meeting, the tech lead says:
"We have 58% coverage on the billing service. Before we add any new features there, I want us to get it to at least 75%. How should we prioritise which files to test first?"
Which prioritisation strategy is most defensible?
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
5 / 10
A code review comment reads:
"This PR drops overall coverage from 83% to 79%. The change is 4 files totalling 340 lines of new code with 0 tests. I'm blocking this until we reach at least 80%."
How would you respond professionally?
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?"
6 / 10
Sarah, the lead developer, sends this message to the team after reviewing a recent pull request:'The coverage report shows 72% overall. We've added 150 new lines of code in the user authentication module, but only 60% of those are covered by tests. This is below our target of 85%. Can someone investigate why?'
Which of the following actions should she request first?
Sarah's message highlights a specific area of concern (authentication) and a quantifiable metric (60% coverage). Option A is too aggressive; simply rewriting tests isn't an immediate solution. Option C focuses solely on the module without considering the root cause. Option D implies a fundamental flaw in the code, which may not be immediately obvious from coverage alone – this option's urgency is overstated. The correct response is to investigate the *reason* for the low coverage, acknowledging that 72% is a starting point.
7 / 10
During a standup meeting, David states: 'Our latest build has 95% line coverage across the entire application, but we've just identified a regression in the reporting service that caused incorrect sales figures. It appears to be related to a change made two weeks ago.'
What is the most important takeaway from this statement for the team?
David's statement is crucial: high line coverage doesn't *guarantee* stability. The regression demonstrates that even with extensive testing, unexpected issues can arise due to complex interactions or overlooked scenarios. Option A misinterprets the value of code coverage; it's a tool, not a guarantee. Option C correctly points out the key limitation – coverage alone is insufficient for robust quality assurance. Increasing coverage without addressing the root cause (the change two weeks prior) would be a wasted effort.
8 / 10
You are reviewing a pull request that includes changes to a complex data processing pipeline. The code coverage report shows an overall increase from 68% to 75%, but the reviewer notes that several key nodes in the pipeline (specifically, those handling user input validation) have very low test coverage (around 30%).
Which of the following is the most appropriate next step?
While an overall increase in coverage is positive, focusing on areas with *low* coverage – particularly critical nodes like user input validation – is far more strategic. Option A ignores the specific concerns raised by the reviewer. Option C is a generic approach that doesn't address the immediate risk. Option D is entirely inappropriate; testing should happen before deployment. The correct action is to investigate and prioritize testing those vulnerable areas.
9 / 10
A senior engineer posts this message on Slack:'We're aiming for 90% coverage across the entire API. The build just ran and showed 87%. It flagged a few new files added in the v2 integration – they're currently at 55% coverage. Should we focus on getting those to 90% before tackling the rest?'
What's the best way to respond?
The Slack message highlights a recent change (v2 integration) with low coverage. Prioritizing this area is crucial because it represents a potentially unstable part of the system. Option A is indiscriminate; focusing solely on the overall percentage isn't effective. Option C ignores the specific risk. Option D suggests a thorough review, which might be necessary later, but immediate prioritization is needed.
10 / 10
During a code review discussion, Mark states: 'Our new microservice has 78% line coverage. We've been using branch coverage analysis to identify the most critical paths for testing. The results show that only 20% of the branches are covered.'
What does this indicate?
Low branch coverage indicates that tests are primarily focusing on lines of code rather than exploring different execution paths. This means the tests may not be uncovering critical bugs or edge cases. Option A suggests refactoring – a possible outcome but isn't necessarily implied by the data alone. Option C misinterprets low branch coverage; it's a signal for improvement. Increasing line coverage without addressing branch coverage won't guarantee better test effectiveness.
This module focuses on Numbers, Data & Metrics — real workplace phrasing you'll use on the job. It contains 10 scenario-based multiple-choice questions with instant feedback.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account or sign-up required.
How many questions does this exercise have?
This module includes 10 questions. Each one gives an immediate right/wrong result plus a full explanation of the correct phrasing.
What happens if I answer a question incorrectly?
You'll see the correct answer highlighted straight away, along with a plain-English explanation of why it's right and why the other options don't fit — mistakes are part of the learning here.
Can I retry the exercise if I want a better score?
Yes — use the 'Try again' button on the results screen to reset your score and go through the questions again. There's no limit on attempts.
Who is this Numbers, Data & Metrics exercise for?
It's aimed at IT professionals with working English who want to sound more natural and precise around numbers, data & metrics — useful whether you're preparing for real conversations at work or just building confidence with the vocabulary.
Do I need an account to track my progress?
No account is needed. Your progress through the exercise is tracked locally in your browser for the current session, and you can replay the module at any time.
How is this different from reading a blog article?
This exercise is an interactive drill that tests and reinforces specific phrasing through multiple-choice questions with instant feedback, while blog articles explain concepts and vocabulary in prose. The two work well together.
Where can I find more Numbers, Data & Metrics exercises?
See the Numbers, Data & Metrics hub for more modules like this one, or browse the full Exercises page for other IT-English topics.
Can I complete this exercise on my phone?
Yes — every exercise on CoderSlingo is fully responsive and works on phones and tablets, so you can practise anywhere.