Test Coverage
Test Coverage — why it matters
Coverage tools report which statements, functions, and branches ran during a test suite. High coverage can expose untested code, but it does not prove tests assert the right behavior. Aim for meaningful boundary and failure-case tests rather than maximizing one percentage in isolation.
What you’ll learn
- Explain test coverage and the problem it solves.
- Identify the relevant compile-time checks and runtime responsibilities.
- Run the example, predict its output, and try a realistic modification.
Understand the mechanism
Both branches are exercised by two calls, making branch coverage for this tiny function complete. A test runner must still assert that the outputs are correct, not just execute them.
100% line coverage is not proof of correctness, security, or adequate edge-case testing.
Follow the concept flow
Run the primary TypeScript example
Save as test-coverage.ts. The following program passed strict TypeScript compilation, and the displayed output was captured by executing its emitted JavaScript with Node.js 22.16.0.
TypeScript source
function describeScore(score: number): string {
if (score >= 50) return "Pass";
return "Try again";
}
console.log(describeScore(80));
console.log(describeScore(25));Verified output
Pass
Try againCompile: npx tsc --strict --target es2022 --module commonjs test-coverage.ts; run: node test-coverage.js. For Node.js API examples, install @types/node first. For browser projects, use the browser-specific instructions below.
The example demonstrates the code-level behavior; the related configuration or test commands are shown separately when needed.
Trace the result
Both branches are exercised by two calls, making branch coverage for this tiny function complete. A test runner must still assert that the outputs are correct, not just execute them.
Predict what changes if you alter one input. Then run the code to compare your reasoning with the real output.
Try the full tool or configuration workflow
Practical project lab: These are real configuration and source-file examples, not a TypeScript object that merely describes settings. Place the files at the named paths relative to one project directory.
score.ts
export const pass = (n:number):boolean => n>=50;score.test.ts
import {test} from "node:test";
import {strict as assert} from "node:assert";
import {pass} from "./score";
test("both branches",()=>{ assert.equal(pass(60),true); assert.equal(pass(40),false); });Commands
npx tsc --strict --module commonjs --target es2022 score.ts score.test.ts
node --experimental-test-coverage --test score.test.jsCoverage describes executed code paths, not correctness of expectations.
This local compiler or test-runner mini-project was validated in addition to the primary program.
Common mistake and correction
100% line coverage is not proof of correctness, security, or adequate edge-case testing.
Identify whether the failure is a type-checking issue, a configuration issue, or a runtime behavior issue before choosing a fix.
Practice the concept
Use a runner's --coverage option. Remove the failing-score case and observe the branch coverage report.
Write down your expected result first. For configuration examples, compare compiler output and diagnostics; for test examples, make the assertion fail deliberately to verify that the tool reports it.
Check your understanding
What to remember
Coverage tools report which statements, functions, and branches ran during a test suite.
Run the primary example, then complete the practice task or environment-specific lab.
Reaching the recap and completing the quizzes are separate milestones.