The last exercise left you with an uncomfortable fact: coverage said 100%, and the suite caught nothing. You need a measurement that asks the real question, would these tests notice if the code were wrong? Mutation testing answers it by trying. You’ve already been doing it by hand: every exercise in this course ran your tests against “mutants”. A tool does the same thing systematically, for every line.
\n< becomes <=, + becomes -, Math.min becomes Math.max, a condition becomes true, a block is emptied.It repeats this for hundreds or thousands of mutants. The mutation score is the percentage killed.
\nCoverage asks “did this line run?” Mutation testing asks “if this line were wrong, would anyone notice?” The second question is the one you care about.
\nStrykerJS is the established mutation testing tool for JavaScript and TypeScript, with a runner plugin for Vitest:
\nnpm install --save-dev @stryker-mutator/core @stryker-mutator/vitest-runner\nnpx stryker init # interactive; or write the config yourself{\n \"$schema\": \"./node_modules/@stryker-mutator/core/schema/stryker-schema.json\",\n \"testRunner\": \"vitest\",\n \"plugins\": [\"@stryker-mutator/vitest-runner\"],\n \"mutate\": [\"src/money/**/*.js\", \"!src/**/*.test.js\"],\n \"reporters\": [\"html\", \"clear-text\", \"progress\"],\n \"thresholds\": { \"high\": 80, \"low\": 60, \"break\": 50 },\n \"incremental\": true\n}npx stryker run first runs your suite once to see which tests cover which lines, then tests every mutant. The HTML report shows your source with each mutant marked killed or survived. thresholds.break fails the run below that score, and incremental reuses results for code and tests that didn’t change since the last run, which matters a lot for speed.
The statuses you’ll see most:
\nSurvivors are the gold. For settleUp, a report might say:
[Survived] MethodExpression src/money/settle-up.js:21\n- const amountCents = Math.min(debtors[d].cents, creditors[c].cents);\n+ const amountCents = Math.max(debtors[d].cents, creditors[c].cents);\n\n[Survived] ConditionalExpression src/money/settle-up.js:4\n- if (sum !== 0) throw new Error('Balances must add up to zero');\n+ if (false) throw new Error('Balances must add up to zero');Each one is a precise instruction. The first says no test uses amounts where the debtor owes a different sum than the creditor is owed, so min and max give the same answer in every test. The second says no test ever passes unbalanced input. Write those two tests and both mutants die.
The mutants in this course’s exercises were hand-picked: each one imitates a bug a person really writes, like a swapped argument or a forgotten await. Stryker’s are generated systematically from a fixed set of mutators, typically dozens per function, so it finds gaps you would never think to look for, and also produces some noise. Both are useful. When you review a teammate’s tests, the hand-picked habit is the quick version: ask “what is the most likely bug here, and which test would fail?” When you want a measurement across a whole module, let the tool generate the list.
Mutation testing is slow: hundreds of mutants, each running part of your suite. A few habits keep it practical:
\nmutate to the code where bugs are expensive: money, permissions, parsing. Not UI glue.In the exercise you get a weak settleUp suite and a list of survivors, and you write the tests that kill them.
Stryker reports: ConditionalExpression: if (sum !== 0) → if (false) — Survived. What does that tell you?
settleUp to throw.","why":"Correct. Add a test like expect(() => settleUp({ Ana: 500, Ben: -400 })).toThrow() and the mutant is killed."},{"text":"Stryker failed to run the tests for that line.","why":"When tests can’t run, the status is a runtime or compile error, or “no coverage”; “Survived” means the tests ran and all passed."}],"answer":1},{"q":"Your suite has 100% line coverage and a mutation score of 55%. Which is the better summary?
","options":[{"text":"Every line runs, but nearly half of the plausible bugs Stryker introduced would go unnoticed.","why":"Correct. Coverage shows execution; the mutation score shows how much of that execution is actually checked."},{"text":"The suite is excellent; mutation scores above 50% are rare.","why":"There’s no universal bar, but 45% surviving mutants on core logic usually means weak assertions worth fixing."},{"text":"The two numbers contradict each other, so one of the tools is misconfigured.","why":"They measure different things; high coverage with a low mutation score is the classic pattern of assertion-light tests."}],"answer":0},{"q":"A mutant changes b.cents - a.cents to a.cents - b.cents in the sort comparator, and every valid input still produces a correct settlement. What should you do?
This settleUp suite passes, but Stryker’s report (copied into the starter’s comment) lists three mutants that survived it: Math.min changed to Math.max, the zero-sum check disabled, and the minus sign dropped when recording what a debtor owes. Last month’s code review found a fourth bug the suite also misses: from/to swapped in each transfer.
Write the tests that kill all four, without breaking the suite on the real code. The subject is the settleUp you built in the TDD lesson.
toHaveLength(1) can’t tell a correct transfer from a wrong one. Assert the whole transfer with toEqual([{ from: 'Ben', to: 'Ana', amountCents: 500 }]); that kills two mutants at once.","Math.min and Math.max agree whenever the debtor owes exactly what the creditor is owed. Use one debtor and two creditors with different amounts, such as { Ana: -1000, Ben: 600, Cai: 400 }.","For the disabled check, pass balances that don’t add up to zero and expect a throw: expect(() => settleUp({ Ana: 500, Ben: -400 })).toThrow()."],"explanation":"Each survivor maps to one missing assertion. The swapped direction and the dropped minus sign both survived because toHaveLength(1) never looked inside the transfer; asserting the exact transfer kills both (one produces Ana paying Ben, the other a transfer of -500). Math.max survived because in every test the debtor owed exactly what the creditor was owed, so min and max agreed; with one debtor owing 1000 and creditors owed 600 and 400, max pays Ben 1000 and stops, so the exact list fails. The zero-sum check survived because no test ever sent unbalanced input. Notice what you didn’t need: a test of the sort order for large groups. That mutant would be equivalent in many cases, and pinning it would test the implementation, not the behaviour.