Mutation-guided test strengthening

How it works

Mutation testing makes small deliberate changes to the code — flip a comparison, remove a call, change a constant — and checks whether any test fails. A mutant that survives shows a behaviour the tests don't actually check, which code coverage can't reveal. The technique is long established; the slow part has always been acting on the results, since a large codebase can produce thousands of survivors. A model reads each surviving mutant with the surrounding code and tests and drafts a test that would kill it, or explains why the mutant is equivalent to the original and can't be killed. The new test is run against the mutant to confirm it fails, then against the original to confirm it passes.

When to use it

Critical modules where test strength matters more than speed, such as calculations, authorisation and data handling; suites with high line coverage but suspected weak assertions; and as a check on AI-generated tests, which are prone to asserting too little.

Limitations

Mutation testing is computationally expensive and is best scoped to the code that matters. Killing a mutant is not the same as testing a requirement — a test written to catch one specific mutation can be narrow and brittle. Some survivors are equivalent mutants that no test can kill, and models misjudge which ones those are in both directions.

What you still own

Choosing where to apply mutation testing, and judging whether each new test checks behaviour that actually matters.

Cite this