Mutation Testing with Stryker — Measure Test Quality • Meteora Web Agency

Your test suite says 85% code coverage. But how many of those tests would fail if someone introduced a bug? If you don't know, you're just counting executed lines, not verifying quality. Mutation testing answers this brutally: it injects errors into your code and checks if tests catch them. At Meteora Web, we use it on critical projects because we know a production bug costs more than any test suite. This guide covers how Stryker works, how to read its reports, and how to integrate it into your workflow without slowing development.

What does mutation testing measure that coverage doesn't?

Code coverage only tells you which lines are executed. It doesn't tell you if assertions are meaningful. A test that calls a function without checking the result boosts coverage but protects nothing. Mutation testing goes further: it takes your code, applies small changes — flips an operator, inverts a condition, removes a call — and re-runs tests. If tests don't fail, you've found a survived mutant: a bug your suite would have missed.

Concrete example: a useless test that passes

Imagine a discount function:

function calculateDiscount($price, $percent) {
    return $price - ($price * $percent / 100);
}

A test that calls this without assertions gives 100% coverage. Stryker mutates $price - to $price +, and the test still passes. Result: survived mutant. Your test is worthless. This is why coverage alone is a misleading metric.

How does Stryker work and why choose it?

Stryker is the most mature mutation testing framework for JavaScript/TypeScript and PHP. It works with major test runners — Jest, Vitest, PHPUnit, Mocha — and integrates into CI pipelines. Its engine applies dozens of mutators: changes arithmetic/logic operators, removes conditions, alters strings, deletes function calls. For each mutant, it re-runs tests and generates a detailed report.

Why Stryker over alternatives?

We've tried Infection for PHP and Pitest for Java. Stryker has a more uniform ecosystem: same interface for JS and PHP, clear HTML reports, parallel testing support. With Stryker PHP and Stryker JS, you cover both worlds with a single learning curve. Plus, its free dashboard for open-source projects gives you metric history over time.

How to read Stryker's report to improve tests?

Stryker's HTML report is the core of analysis. Each mutant is classified: killed (tests fail), survived (tests pass), and timeout (test loops — often a real bug). The key metric is the mutation score: percentage of killed mutants over total.

Priority: which survived mutants to tackle first?

Not all survivors are equal. A mutant changing > to >= in an access control is critical. One altering a log string is less urgent. With Stryker, filter by mutator type and file. We recommend starting with files containing more business logic — calculations, authorizations, payment handling — and ignoring irrelevant edge cases. The goal isn't 100%, but a score above 80% in critical areas.

How to integrate Stryker into the development workflow without slowing down?

Mutation testing is computationally heavy: for each mutant, it re-runs the entire test suite. On large projects, it can take hours. That's why it belongs in CI, not locally on every commit. The strategy we use: run Stryker on targeted pull requests, limiting to changed files. This way, feedback arrives in minutes without blocking developers.

Minimal Stryker JS config with Jest

{
  "$schema": "./node_modules/@stryker-mutator/core/schema/stryker-schema.json",
  "testRunner": "jest",
  "coverageAnalysis": "perTest",
  "mutate": ["src//*.js", "!src//*.test.js"],
  "reporters": ["html", "clear-text", "progress"]
}

This tells Stryker to mutate only src files, excluding tests. coverageAnalysis: perTest speeds up execution by associating each test with files it touches.

Command to run Stryker in CI (GitHub Actions)

- name: Run mutation testing
  run: npx stryker run
  env:
    STRYKER_DASHBOARD_API_KEY: ${{ secrets.STRYKER_DASHBOARD_API_KEY }}

With this pipeline, every pull request touching src gets a report. If the mutation score drops below the configured threshold, the PR is blocked. Starting with a 70% threshold on core modules is a good first step.

What mistakes to avoid when adopting mutation testing?

The first mistake is applying it to all code at once. The result? Slow builds and frustration. The second is ignoring survived mutants: if you don't analyze them, the tool becomes noise. The third is writing tests that kill mutants but don't verify real behavior — for example, tests checking only internal implementation. We've seen teams add useless assertions just to raise the score. Remember: mutation testing is a means to find gaps in tests, not an end.

How to set a realistic threshold

There's no magic percentage. For an e-commerce, the payment module should be above 90%. For a blog, 70% is acceptable. Start with a low threshold, monitor reports, and raise it gradually. Stryker's dashboard shows trends over time, so you can see if you're improving or if new tests are just fluff.

Mutation testing and TDD: how do they complement each other?

If you practice Test-Driven Development, mutation testing is your ally. Writing tests first, then code, produces tests born to verify behavior. Stryker tells you if that test is strong enough. We see it often: a test that seems solid, but a survived mutant reveals a missing edge case. It's feedback TDD alone doesn't provide.

Alternative tools and when to use them

Besides Stryker, there's Infection for PHP and Pitest for Java. If your project is pure PHP, Infection is mature and fast. But if you work in a mixed environment, Stryker gives you a single interface. At Meteora Web, we use Stryker for Laravel and Vue projects, and Infection for legacy PHP codebases. The choice depends on your stack, but the concept is identical: measure test quality, not quantity.

What to do now

Here are three concrete actions to start today:

Install Stryker in your project with npm install --save-dev @stryker-mutator/core and configure the appropriate runner (Jest, Vitest, PHPUnit).
Run Stryker on a critical module — like payment or authentication logic — and analyze survived mutants. Write additional tests for missing cases.
Integrate Stryker into CI with a minimum mutation score threshold for pull requests. Set up the dashboard to track progress.

Mutation testing isn't a luxury. It's the only way to know if your tests are worth anything. If you want to see it applied in a real project, check our guide on test strategies to see where it fits in the pyramid. For official documentation, visit Stryker Docs.