Trimming Mutation Scope: Files, Operators and Lines

The cheapest mutants are the ones you never generate. Two scoping moves do most of the work, and both are available in mainstream tools.

The first is incremental mode. StrykerJS tracks changes to mutated files and test files and reuses prior results, printing a line like Result: 3731 of 3965 mutant result(s), meaning only 234 mutants need to run the incremental announcement. Read the limitations carefully: incremental mode does not detect changes in other files, in dependencies, in environment variables or in snapshot files, and static mutants have no test coverage so test changes are not detected for them the incremental limitations. Treat incremental runs as the fast default in CI and a full run as a scheduled safety net. Interrupted runs resume where they stopped, which matters when a timeout or a canceled pipeline eats a three-hour job the incremental docs.

The second is explicit scoping. StrykerJS lets you narrow the target with a mutate pattern, down to a line range, and combine it with --force so scoped mutants rerun even if the incremental file says they are unchanged the incremental announcement. The pattern below is the shape of a CI-friendly invocation: change detection decides the file list, the pattern decides what is mutated, and force keeps the scoped report honest.

# Mutate only the files the change touches, then write a full report
npx stryker run --incremental --force --mutate "src/pricing/**.ts,src/cart/**.ts"

The open-source diff_cover project shows how to compute the changed-line set that feeds such a list: it compares an XML coverage report against git diff and reports coverage only for new or modified lines, producing the percentage of changed lines that tests touch the diff-cover repository. The same diff logic generalizes: your "changed files plus direct dependents" set is the file list for mutation, and anything outside it waits for the next full run. The edX team described the cultural effect of this shift: focus on the quality of a single pull request instead of a project-wide number, and developers start writing tests for their own changes the Open edX write-up on diff-cover. Bitcoin Core's plan lists nearly identical steps: skip a file's weekly analysis if neither the file nor its tests changed, and skip generating mutants for lines with no test coverage the Bitcoin Core write-up.

One scoping caveat. Google's large-scale approach mutated only changed code during code review and added filtering plus historical operator performance, reporting orders of magnitude fewer mutants across more than 1,000 projects the Google experience paper. The lesson is that scoping is an accepted industrial practice, not a shortcut. The caveat is that a file changed indirectly, such as a shared constant consumed elsewhere, may not appear in your diff; direct dependents catch most of that, and the scheduled full run catches the rest.

Most tool default operator sets were chosen for fault-detection power, not for cost per actionable survivor. That is why the default set feels wasteful: you pay to run mutants no test can ever kill. The equivalent-mutant problem is undecidable in general, meaning no algorithm detects every equivalent mutant, and developers have historically inspected survivors by hand the AI-enhanced mutation testing survey. The Marsit et al. study argues that estimating the equivalent-mutant ratio beats painstaking identification: if you generate 100 mutants for a program and estimate the ratio at 0.2, you know about 80 are semantically distinct and you can measure test thoroughness against 80 rather than 100 the equivalence study. You do not need to find each equivalent mutant; you need to know which operators make them.

Here is a decision rule with made-up numbers to show the arithmetic. Say a full run generates 4,000 mutants at 3.5 seconds each, about 3.9 hours. Of the 1,600 survivors, sorted by operator, the boundary-operator mutants are 25 percent equivalent, while the logical-connector mutants are 55 percent equivalent. Dropping the worst operator family removes 600 generated mutants and 0.6 hours of generation plus the time spent triaging roughly 200 mutants nobody can kill. The survivors you actually want, the stubborn ones, are almost all in the operator families you kept.

The ICSE study gives a direction to test against your own ledger: prioritize operators that generate stubborn mutants and few equivalent ones, because operators heavy in equivalent mutants skew results and waste effort trying to kill them the ICSE study. A practical way to estimate per-operator rates without hand analysis is to seed known-equivalent transformations yourself. For instance, the sequence x > 0 to x >= 1 over integers is a classic equivalence, and if your tool offers a constrained operator variant, you can compare what it generates against a manually curated set of equivalent pairs.

Static mutants deserve their own line because they are the worst cost per mutant. A static mutant executes once at startup instead of during test execution, so activating or deactivating it does not change behavior; tools handle them either by running all tests against them or by ignoring them, and the documentation notes that running them gives them a fresh test environment with a big performance impact the static mutants page. Ignoring them is a legitimate scope decision, not a failure, as long as your report states the policy.

Subsumption is the ordering insight that separates a useful triage list from a backlog of 400 "review me" entries. If mutant A subsumes mutant B, any test that kills A also kills B. Kill the dominators and their descendants fall for free. PRIMG, a framework for LLM-driven test generation on Solidity contracts, trained a model on mutant subsumption graphs to predict the usefulness of surviving mutants and found its prioritization consistently beat random mutant selection, producing high-impact tests with less computational effort the PRIMG paper. The lesson transfers: a test written for a dominating mutant covers its descendants on the first try.

You do not need a trained model to get most of the benefit. A plain procedure works on your own survivor list:

1. Group survivors by mutated line and operator class. Within a line, boundary and comparison operators often produce small, nearly interchangeable families.
2. For each survivor, list the tests that cover the original line (from the coverage report) and check whether every test fails when that mutant is forced. The set of killing tests is the mutant's behavior signature.
3. If mutant A's killing test set is a strict subset of mutant B's, then A is harder to kill than B, meaning A is a better target. A test that kills A will often kill B too.
4. Sort survivors by "tests that kill it" ascending, then by file runtime descending, and spend your writing time from the top.

A worked example with numbers, using hypothetical results: you have 180 survivors across one module. Grouping by behavior signature collapses them into 42 distinct signatures. Writing one targeted test for each of the 42 top signatures costs 42 test-writing slots; if the subsumption graph is dense, those 42 tests kill an estimated 140 to 160 of the 180 survivors, because each signature covers a share of the remaining mutants. The 20 to 40 leftovers are mostly equivalent or static, and the next run's ledger tells you which. The granularity caveat matters here: Márki's thesis points out that the subsumption hypothesis is rejected once mutants are judged on function return values, and masking behavior depends on how execution is observed the subsumption thesis. Compare survivors using the same kill criterion the tool reports, or your ordering will misfire.

Test-prioritization research offers a complementary trick: reorder tests so the one that kills a mutant runs earlier, and reduce the test set per mutant so a surviving mutant does not need every test to prove it survives the FaMT paper. The effect is the same budget logic: spend test executions on informative mutants and stop spending them on uninformative ones.

Once the operator set and file list are trimmed and the survivors are ranked, decide where each run happens. A workable three-tier split looks like this.

In each tier, tune the reporting to the actionable number: killed mutants that were stubborn the last time, not raw mutation score. Google's setup tied mutation testing to code review and limited mutants per line and per review, so developers saw a small, relevant set rather than the whole combinatorial explosion the Google experience paper. The Bitcoin Core team names the same goals explicitly: generate productive mutants, skip files with no relevant changes, and skip lines without coverage the Bitcoin Core write-up.

Teams that generate tests with coding agents can shorten the loop further: agent skills can adopt your operator policy and survivor ranking as standing instructions, so the next PR's test additions target dominators first. If your pipeline already runs ML and LLM services for triage and test drafting, one point worth knowing is that Quanta Inference exposes text, image, video, audio and embedding models through a single OpenAI-compatible API, which keeps cost accounting in one place. But the decisive change is policy, not tooling: a trimmer operator set, a scoped file list, and a subsumption-ordered survivor queue turn a multi-hour weekly bill into a steady trickle of meaningful tests.