Book 10 · Testing & QualityPage 17 of 36

Mutation Testing

In Turkish: Mutasyon Testi

Updated September 30, 20262 min read

In short

Mutation testing measures the quality of a test suite by inserting small deliberate bugs into the code and checking whether the tests fail and catch each one.

What is mutation testing?

Mutation testing evaluates your tests rather than your code. A tool deliberately introduces small bugs, called mutants, into the program and runs the test suite against each one. If at least one test fails, the mutant is killed; if every test still passes, the mutant survived, which reveals behavior that no test actually checks.

Mutants are created by mutation operators, simple rules such as changing > to >=, + to -, true to false, replacing a return value, or deleting a line. The tool reports a mutation score, the percentage of mutants killed, and lists the survivors so you can add missing tests. Because the suite must run once per mutant, tools save time by running only the tests that cover the changed line or by mutating only the code changed in a pull request. Some mutants are equivalent, meaning the change doesn't alter behavior at all, so no test could ever kill them.

Mutation testing is like a fire drill with a hidden practice fire: it tells you whether your alarms actually go off. Teams use it on critical business rules and libraries, and to check whether a high coverage number means anything.

Mutation testing is often confused with test coverage. Coverage tells you which lines ran during the tests, while mutation testing tells you whether the tests would fail if those lines were wrong. A test with no assertions can reach 100% coverage and still kill zero mutants. It also differs from fuzz testing, which mutates the inputs to a program instead of the program's code.

Key takeaways

Mutation testing inserts small bugs, called mutants, to test the tests.
A mutant is killed when a test fails and survives when all tests pass.
The mutation score is the percentage of mutants the suite killed.
It exposes weak assertions that coverage numbers cannot reveal.
Running the suite once per mutant makes it slow, so tools narrow the scope.

Example

A surviving mutant and the test that kills itjavascript

// Original code
function canVote(age) {
  return age >= 18;
}

// A mutant the tool generates: ">=" changed to ">"
function canVoteMutant(age) {
  return age > 18;
}

// This test passes for BOTH versions, so the mutant survives:
assert.equal(canVote(30), true);

// A boundary test kills the mutant, because it fails on the mutated code:
assert.equal(canVote(18), true);

Readers ask

What is a good mutation score?

There is no universal target, but many teams treat 70 to 80 percent as healthy for important code. Surviving mutants are most useful as a to-do list of missing checks rather than as a number to maximize.

Why is mutation testing slow?

The test suite has to run against every mutant, and a large codebase can produce thousands of them. Tools speed this up by running only the tests that cover each mutated line and by mutating only recently changed code.