Mutation Testing — Stryker Guide for QA Teams (2026)

Last updated 2026-07-20 · 10 min read · By Avinash Kamble, reviewed by Priyanka G.

90% code coverage means nothing if the tests only call the code and never assert. Mutation testing tools like Stryker prove this by mutating your source and checking if any test fails. A surviving mutant = a missing assertion. This is the metric that actually correlates with production defect rate.

Key takeaways

• Why coverage lies and mutation score does not.
• Stryker setup for JS/TS and Java.
• Reading the mutation report.
• Hitting 80% mutation score without doubling test time.

function add(a, b) { return a + b; }
test('add works', () => { add(1, 2); });  // 100% coverage, zero assertions

Stryker would change a + b to a - b and the test still passes — a "surviving mutant." That is your bug.

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

Report at reports/mutation/mutation.html. Java equivalent: PIT.

• Killed — mutant broke a test. Good.
• Survived — mutant lived. Missing assertion.
• No coverage — line not tested at all.
• Timeout — usually loop or recursion mutation.

Scope Stryker to changed files only in PR CI (Stryker supports git diff). Full run nightly. Focus on domain code — skip config, DTOs, and generated code. Related: flaky tests, test data management. Docs: stryker-mutator.io.