Why do equivalent mutants put a ceiling on any mutation score?

### The definition An **equivalent mutant** is a mutant whose behaviour is indistinguishable from the original program for every possible input. The source text changed; the observable behaviour did not. Because no input can make it behave differently, no test can ever make a test fail on it, and it therefore sits permanently in the survivor list. That is the ceiling. If a run generates 1,438 mutants and 92 of them are equivalent, the highest score any suite could ever reach is roughly 93.6% — and no amount of test writing will close the remaining gap, because the gap is not a defect in the suite. A team that treats 100% as the target will burn effort trying to kill unkillable things, or worse, will contort production code to remove them. ### Why they cannot be detected automatically Deciding whether two programs are behaviourally equivalent is undecidable in general — it reduces to the halting problem. There is no algorithm that takes a mutant and its original and always answers correctly. Tools can therefore only apply heuristics: compiler-style equivalence checks, constraint solving over the changed expression, detecting mutants whose changed code is provably unreachable, or refusing to generate operator/site combinations that are known to produce equivalents often. All of these reduce the population; none eliminates it. The residue is triaged by a human, and that triage is the technique's main hidden cost — reported effort in the literature runs to minutes per mutant, and studies typically find equivalents to be a small but non-trivial single-digit-percentage share of generated mutants. ### The shapes you will actually meet - **Redundant conditions.** A bound that is already guaranteed by an earlier check. Changing `<=` to `<` on a value that can never equal the bound changes nothing. - **Unreachable-in-practice branches.** Defensive code that a caller contract already excludes. - **Optimisation-equivalent arithmetic.** An edit that a compiler or the runtime would fold to the same result. - **Unobservable state.** A mutated field write that nothing ever reads, or a mutated value that is overwritten before use. - **Ordering that does not matter.** A change to the order of operations over a commutative combination, or to iteration order where the result is a set. ### A worked example In the grant-application review queue, applications are held in a priority order and a background sweep re-scores them nightly. One helper clamps a computed urgency score into a range before storing it. The score is produced by a function whose codomain is already inside that range, so a boundary mutant that changed the upper clamp from "at most 100" to "below 100" produced a mutant no input could distinguish. It survived the 6-hour nightly run, as it had survived every run for months. Contrast that with a survivor in the same run that *looked* equivalent and was not: a mutant in the reviewer-eligibility guard that removed a redundant-seeming re-check of the submitter identity. A reviewer following the ordinary path could never reach it with a self-submitted application, so the mutant appeared harmless — but a second entry point, the bulk-decision endpoint, reached the guard without the earlier check. The mutant modelled a real permission escalation. The lesson is the one that makes this a senior topic: "I can't think of a test that kills it" is not the same claim as "no test can kill it", and the first is what an engineer under time pressure actually means. ### Living with the ceiling The practical discipline is to stop treating the raw score as the target and start treating the survivor list as a work queue. 1. **Never set the goal to 100%.** Set it relative to the achievable ceiling, or better, drop the absolute target and require that new survivors introduced by a change are triaged. 2. **Record the verdict, don't re-derive it.** Once a survivor is judged equivalent, suppress it with a durable marker and a written justification, so the next run does not re-present it. An unjustified blanket suppression is how a real gap gets hidden, so the justification is the artefact that matters, not the suppression. 3. **Re-open suppressions when the code around them changes.** Equivalence is a property of the surrounding context, and the clamp that was equivalent yesterday stops being equivalent the moment the scoring function's range widens. 4. **Prefer trends to absolutes.** Equivalents are roughly stable for stable code, so movement in the score is meaningful even when its absolute value is not. 5. **Consider deleting the redundant code.** Many equivalent mutants sit on genuinely dead defensive checks. Removing them raises the ceiling and simplifies the code — though a check kept deliberately as a safety net is worth keeping and suppressing instead. ### Why interviewers ask it It is a differentiator rather than a gate. A candidate who knows only that "mutation testing kills mutants" will assert that a low score always means weak tests. A candidate who names equivalent mutants, explains the undecidability behind them, and describes triage as an ongoing cost has clearly run the technique on a real codebase rather than read about it.