Mutation Testing

1 The Hook

A Wellington bank’s QA team presents their quarterly quality report to the CTO. 94% code coverage across all services. The CTO is satisfied.

That same quarter, a boundary condition in the interest calculation is wrong. The <= should be < for daily interest accrual. The bug is in a function with 100% statement coverage. Every line of that function executes in the tests. But the test only asserts calculateInterest(10000) > 0 — it never checks the actual value.

A mutation test would have replaced <= with < and observed the tests still pass. The mutation would have survived. 100% coverage, 0% detection of this specific bug.

The quarterly report was not lying. It was measuring the wrong thing.

2 The Rule

3 The Analogy

4 Watch Me Do It — Stryker on a NZ Interest Calculation

Here is the function under test: a simple daily interest calculator for a NZ lending product.

// src/interest.js
function calculateDailyInterest(principal, annualRate, days) {
  if (days <= 0) return 0;
  return principal * (annualRate / 365) * days;
}

A weak test that gives 100% coverage:

test('calculates interest', () => {
  const result = calculateDailyInterest(10000, 0.05, 30);
  expect(result).toBeGreaterThan(0); // ← asserts nothing specific
});

Every line executes. Coverage: 100%. But look at what Stryker creates when it mutates the function:

• Change <= to < in the boundary check → test still passes (positive days still work, result is still > 0)
• Change annualRate / 365 to annualRate / 366 → test still passes (result is still > 0)
• Change * to / in the multiplication → test still passes (tiny fraction, but still > 0)

All three mutants survive. Your mutation score for this function: very low.

Fix it with a test that actually asserts on the value:

test('calculates 30-day interest on $10,000 at 5% p.a.', () => {
  // 10000 * 0.05 / 365 * 30 = 41.096...
  expect(calculateDailyInterest(10000, 0.05, 30)).toBeCloseTo(41.10, 1);
  expect(calculateDailyInterest(10000, 0.05, 0)).toBe(0);   // boundary
  expect(calculateDailyInterest(10000, 0.05, -1)).toBe(0);  // negative days
});

Now Stryker kills almost all mutants. The division-by-366 mutant produces 40.98 instead of 41.10 — the toBeCloseTo(41.10, 1) assertion catches it. The boundary mutant is caught by the explicit zero-days assertion.

Running Stryker in a JavaScript project:

npm install --save-dev @stryker-mutator/core @stryker-mutator/jest-runner
npx stryker run

Minimal config (stryker.config.json):

{
  "mutate": ["src/**/*.js"],
  "testRunner": "jest",
  "reporters": ["html", "clear-text"],
  "thresholds": { "high": 80, "low": 60, "break": 50 }
}

Stryker generates an HTML report showing each mutant, whether it was killed or survived, and the exact line. Start with the survived mutants — those are your assertion gaps.

5 When to Use It

Use mutation testing on:

• Financial calculations — interest, GST, tax, exchange rates, loan repayments
• Access control and authorisation logic
• Validation rules — IRD number format, NZBN check digits, date range logic
• Before a major release of a payment or compliance module
• As a periodic audit of a critical library (monthly or per release cycle)

Do not use it as a daily CI gate. Mutation testing is CPU-intensive — it re-runs your entire test suite for every mutant. A suite with 500 tests might generate 2,000 mutants. That is 2,000 full test runs. Run it on a schedule or targeted at high-risk modules. It is a quality audit tool, not a commit gate.

Not suitable for: UI rendering code, generated code, or as a replacement for exploratory and integration testing. Mutation testing only tells you about assertion quality in unit tests. It does not find integration defects or usability issues.

6 Common Mistakes

7 Now You Try

8 Self-Check

Click each question to reveal the answer.

9 ISTQB Mapping

10 Next Steps