Every team that adds tests eventually asks “how much is enough?”, and coverage is the number that seems to answer. It answers a narrower question than people think. Used well, it’s a fast way to find code nobody tested. Used as a score, it rewards the wrong tests.
\nVitest supports two coverage providers. The default, v8, uses the JavaScript engine’s built-in coverage and needs no instrumentation step; istanbul instruments the code and works in more runtimes. Install the provider and run with --coverage:
npm install --save-dev @vitest/coverage-v8\nnpx vitest run --coverageConfigure what to measure and how to report it:
\n/// <reference types=\"vitest/config\" />\nimport { defineConfig } from 'vite';\n\nexport default defineConfig({\n test: {\n coverage: {\n provider: 'v8',\n include: ['src/**/*.{js,jsx}'],\n exclude: ['src/**/*.test.{js,jsx}', 'src/main.jsx'],\n reporter: ['text', 'html'],\n thresholds: { lines: 80, branches: 75 },\n },\n },\n});include matters: in Vitest 4, without it, the report lists only files your tests happened to load, so a completely untested module doesn’t appear at all and the percentage looks better than it is. With include, untested files show up at 0%. The html reporter writes coverage/index.html, which you open in a browser.
if/else, ? :, &&, ||, ??, default parameters).Branch coverage is the one I look at. const share = people > 0 ? total / people : 0; is one line and two branches. A test with three people makes the line 100% covered and the branches 50%, and the untested branch is exactly the edge case from section 2.
The HTML report marks lines that never ran in red and branches that were taken only one way in yellow. That’s the valuable part: red code is untested, guaranteed. No assertion anywhere could have checked it, because it never ran. When I join a project, the coverage report is the fastest map of where the risk lives: the uncovered error handling in the payment module, the else branch nobody hit.
Coverage records execution. It has no idea whether anything checked the result. This test makes computeBalances 100% covered:
test('computes balances', () => {\n const balances = computeBalances([\n { paidBy: 'Ana', amountCents: 3000, splitAmong: ['Ana', 'Ben', 'Cai'] },\n ]);\n expect(Object.keys(balances)).toHaveLength(3);\n});Every line ran. The assertion would still pass if the payer were debited instead of credited, if the shares were floored and a cent vanished, or if a second expense overwrote the first. Coverage: 100%. Confidence: close to zero. The exercise starts from exactly this test.
\n\nAn uncovered line is a question, not an order. Sometimes the right answer is a test. Sometimes it’s deleting the code: a branch nobody can reach, a fallback for a browser you stopped supporting, a helper nothing calls any more. Dead code that is “covered” by a test written only to raise the number is the worst outcome, because now it looks important.
\nThere’s no universal number. Useful rules of thumb:
\nCoverage tells you where tests are missing. To learn whether the tests you have are any good, you need a different tool, which is the next lesson. First, in the exercise, turn a 100%-coverage, catches-nothing suite into one that catches real bugs.
\n","toc":[{"id":"sec-1","text":"Turning it on","level":2},{"id":"sec-2","text":"The four numbers","level":2},{"id":"sec-3","text":"Reading the report","level":2},{"id":"sec-4","text":"What coverage can’t see","level":2},{"id":"sec-5","text":"How much is enough?","level":2}],"takeaways":["Coverage measures which statements, branches, functions and lines ran during the tests, not whether anything checked the results.","The most useful part of a coverage report is the red and yellow it shows you; uncovered code is untested code for certain.","Branch coverage is stricter and more useful than line coverage, because one line can hold several decisions.","Use thresholds as a floor that stops coverage from sliding, not as a target to hit; a number that becomes a goal gets gamed."],"further":[{"title":"Vitest — Coverage guide","url":"https://vitest.dev/guide/coverage"},{"title":"Vitest — Coverage config","url":"https://vitest.dev/config/coverage"}],"quiz":[{"q":"A test calls computeBalances(expenses) and asserts only expect(result).toBeDefined(). Coverage for the file is 100%. What does that tell you?
Line coverage is 100% but branch coverage is 50% for const share = people > 0 ? total / people : 0;. What’s missing?
people is 0 (or negative), so the other side of the conditional runs.","why":"Correct. The line ran, but only one of its two branches did; branch coverage notices, line coverage can’t."},{"text":"A second test with a larger total.","why":"A different total takes the same branch, so branch coverage stays at 50%."},{"text":"Nothing; branch coverage is always lower than line coverage.","why":"It’s often lower, but here it is pointing at a specific untested decision."}],"answer":0},{"q":"Your team sets a hard 90% coverage threshold and makes it a quarterly goal. What is the most likely side effect?
","options":[{"text":"Fewer bugs, because 90% of the code is now verified.","why":"Coverage counts execution, not verification, so the number can rise without bugs falling."},{"text":"Slower CI, because coverage is expensive to collect.","why":"There’s some overhead, but that’s not the main risk of turning the number into a goal."},{"text":"People write tests that execute code without meaningful assertions, so the number rises while confidence doesn’t.","why":"Correct. Once a measure becomes a target, it gets optimised directly; use thresholds as a floor and read the report for gaps instead."}],"answer":2}],"exercise":{"kind":"web","mode":"test","subject":"function splitEvenly(totalCents, people) {\n if (!Number.isInteger(people) || people < 1) {\n throw new RangeError('people must be a positive integer');\n }\n const base = Math.floor(totalCents / people);\n const remainder = totalCents % people;\n return Array.from({ length: people }, (_, i) => (i < remainder ? base + 1 : base));\n}\n\n// Computes each person's balance in cents from a list of expenses.\n// Positive: the group owes them. Negative: they owe the group.\n// Each expense is { paidBy, amountCents, splitAmong: [names] }.\n// - The payer is credited the full amount.\n// - Each person in splitAmong is debited their share from splitEvenly\n// (leftover cents go to the first names in the list).\n// - Balances accumulate across expenses and always add up to zero.\nfunction computeBalances(expenses) {\n const balances = {};\n for (const { paidBy, amountCents, splitAmong } of expenses) {\n const shares = splitEvenly(amountCents, splitAmong.length);\n balances[paidBy] = (balances[paidBy] ?? 0) + amountCents;\n splitAmong.forEach((name, i) => {\n balances[name] = (balances[name] ?? 0) - shares[i];\n });\n }\n return balances;\n}\n","mutants":[{"id":"payer-debited","code":"function splitEvenly(totalCents, people) {\n if (!Number.isInteger(people) || people < 1) {\n throw new RangeError('people must be a positive integer');\n }\n const base = Math.floor(totalCents / people);\n const remainder = totalCents % people;\n return Array.from({ length: people }, (_, i) => (i < remainder ? base + 1 : base));\n}\n\n// Computes each person's balance in cents from a list of expenses.\n// Positive: the group owes them. Negative: they owe the group.\n// Each expense is { paidBy, amountCents, splitAmong: [names] }.\n// - The payer is credited the full amount.\n// - Each person in splitAmong is debited their share from splitEvenly\n// (leftover cents go to the first names in the list).\n// - Balances accumulate across expenses and always add up to zero.\nfunction computeBalances(expenses) {\n const balances = {};\n for (const { paidBy, amountCents, splitAmong } of expenses) {\n const shares = splitEvenly(amountCents, splitAmong.length);\n balances[paidBy] = (balances[paidBy] ?? 0) - amountCents;\n splitAmong.forEach((name, i) => {\n balances[name] = (balances[name] ?? 0) - shares[i];\n });\n }\n return balances;\n}\n"},{"id":"floored-shares","code":"function splitEvenly(totalCents, people) {\n if (!Number.isInteger(people) || people < 1) {\n throw new RangeError('people must be a positive integer');\n }\n const base = Math.floor(totalCents / people);\n const remainder = totalCents % people;\n return Array.from({ length: people }, (_, i) => (i < remainder ? base + 1 : base));\n}\n\n// Computes each person's balance in cents from a list of expenses.\n// Positive: the group owes them. Negative: they owe the group.\n// Each expense is { paidBy, amountCents, splitAmong: [names] }.\n// - The payer is credited the full amount.\n// - Each person in splitAmong is debited their share from splitEvenly\n// (leftover cents go to the first names in the list).\n// - Balances accumulate across expenses and always add up to zero.\nfunction computeBalances(expenses) {\n const balances = {};\n for (const { paidBy, amountCents, splitAmong } of expenses) {\n const shares = splitEvenly(amountCents, splitAmong.length);\n balances[paidBy] = (balances[paidBy] ?? 0) + amountCents;\n splitAmong.forEach((name, i) => {\n balances[name] = (balances[name] ?? 0) - Math.floor(amountCents / splitAmong.length);\n });\n }\n return balances;\n}\n"},{"id":"overwrites-payer","code":"function splitEvenly(totalCents, people) {\n if (!Number.isInteger(people) || people < 1) {\n throw new RangeError('people must be a positive integer');\n }\n const base = Math.floor(totalCents / people);\n const remainder = totalCents % people;\n return Array.from({ length: people }, (_, i) => (i < remainder ? base + 1 : base));\n}\n\n// Computes each person's balance in cents from a list of expenses.\n// Positive: the group owes them. Negative: they owe the group.\n// Each expense is { paidBy, amountCents, splitAmong: [names] }.\n// - The payer is credited the full amount.\n// - Each person in splitAmong is debited their share from splitEvenly\n// (leftover cents go to the first names in the list).\n// - Balances accumulate across expenses and always add up to zero.\nfunction computeBalances(expenses) {\n const balances = {};\n for (const { paidBy, amountCents, splitAmong } of expenses) {\n const shares = splitEvenly(amountCents, splitAmong.length);\n balances[paidBy] = amountCents;\n splitAmong.forEach((name, i) => {\n balances[name] = (balances[name] ?? 0) - shares[i];\n });\n }\n return balances;\n}\n"}],"starter":{"js":"// This suite gives computeBalances 100% line coverage.\n// It also catches almost nothing. Strengthen it.\ndescribe('computeBalances', () => {\n test('computes balances', () => {\n const balances = computeBalances([\n { paidBy: 'Ana', amountCents: 3000, splitAmong: ['Ana', 'Ben', 'Cai'] },\n ]);\n\n expect(Object.keys(balances)).toHaveLength(3);\n });\n});\n"},"solution":{"js":"const sum = (balances) => Object.values(balances).reduce((a, b) => a + b, 0);\n\ndescribe('computeBalances', () => {\n test('credits the payer and debits everyone their share', () => {\n const balances = computeBalances([\n { paidBy: 'Ana', amountCents: 3000, splitAmong: ['Ana', 'Ben', 'Cai'] },\n ]);\n\n expect(balances).toEqual({ Ana: 2000, Ben: -1000, Cai: -1000 });\n });\n\n test('balances add up to zero when the bill does not divide evenly', () => {\n const balances = computeBalances([\n { paidBy: 'Ana', amountCents: 1000, splitAmong: ['Ana', 'Ben', 'Cai'] },\n ]);\n\n expect(balances).toEqual({ Ana: 666, Ben: -333, Cai: -333 });\n expect(sum(balances)).toBe(0);\n });\n\n test('accumulates several expenses paid by the same person', () => {\n const balances = computeBalances([\n { paidBy: 'Ana', amountCents: 2000, splitAmong: ['Ana', 'Ben'] },\n { paidBy: 'Ana', amountCents: 1000, splitAmong: ['Ana', 'Ben'] },\n ]);\n\n expect(balances).toEqual({ Ana: 1500, Ben: -1500 });\n });\n});\n"},"checks":[{"id":"passes","suite":"subject"},{"id":"catches-payer-debited","suite":"payer-debited"},{"id":"catches-floored-shares","suite":"floored-shares"},{"id":"catches-overwrites-payer","suite":"overwrites-payer"}],"title":"From 100% coverage to real confidence","prompt":"The starter test runs every line of computeBalances (and splitEvenly), so a coverage report would show 100%. Yet it checks only that three names come back.
Strengthen the suite until it catches three hidden bugs that the 100% suite misses: one debits the payer instead of crediting them, one floors each share so leftover cents disappear (balances no longer add up to zero), and one overwrites the payer’s balance instead of adding to it when they pay twice. The rules are in the subject’s comment.
\n","hints":["Replace the key-count assertion with the exact result: Ana pays 3000 split three ways, so{ Ana: 2000, Ben: -1000, Cai: -1000 }.","Use a bill that does not divide evenly, such as 1000 between three people, and assert that the balances add up to 0.","Give the same payer two expenses and check that both are counted."],"explanation":"Coverage stayed at 100% the whole time: your new tests ran no line the old one didn’t. What changed is what the tests check. The exact toEqual on the first expense catches the sign error. A bill of 1000 cents between three people leaves a cent over, so floored shares make the balances add up to +1 instead of 0; the sum invariant from section 2 catches it. Two expenses from the same payer exercise accumulation, which a single expense never can, even though the accumulating line was already ‘covered’. That’s the gap between execution and verification, and it’s what mutation testing measures directly.