Add Infection as a non-blocking mutation testing tool for Ember
Date: 05-08-2026 Author(s): Jayden Vicarey (proposal); Anthony (assent) Source: Slack thread
Status
accepted
Context
Ember's PHP test suite is exercised with PHPUnit. Mutation testing can surface gaps in that suite that line/branch coverage may miss. Infection is a well-known PHP mutation testing runner. One engineer has already run it locally on feature branches and proposes adding it to require-dev, with an eye toward pipeline use that posts results as PR comments. The team needs agreement on whether that dependency and workflow are acceptable, and under what constraints relative to existing quality gates (e.g. PHPStan).
Decision Drivers
- Desire for stronger signal on test effectiveness beyond conventional coverage
- Preference that new quality tools not block merges while the practice is still being proven
- Concern about agent/local tooling spontaneously treating Infection like a mandatory gate (similar to how agents may run PHPStan)
- Existing local use of Infection on branches reduces adoption risk for a
require-devdependency - Pipeline value is expected primarily as PR feedback (comments), not as a hard fail
Considered Options
Add Infection to require-dev as informational / non-blocking
Introduce Infection as a development dependency; optionally wire pipeline reporting that comments mutation results onto PRs; keep it out of merge-blocking gates.
Add Infection as a blocking CI quality gate
Require Infection (or a mutation score threshold) to pass before merge, similar to stricter static analysis expectations.
Do not add Infection; keep ad-hoc local use only
Leave Infection out of the repo's declared require-dev and CI; individuals may continue running it privately if installed outside the project.
Decision Outcome
Chosen: Add Infection to require-dev as informational / non-blocking.
Justification: Team consensus supports the dependency when results stay informational. Anthony explicitly accepted the change if Infection is non-blocking (or if agents do not start running it locally in a mandatory/random fashion akin to PHPStan). The proposed PR-comment pipeline use aligns with that informational posture.
Consequences
Positive
- Infection becomes a shared, reproducible
require-devtool rather than a one-off local install - Mutation results can be surfaced on PRs without stopping delivery
- Downstream implementers have a clear constraint: informational reporting first, not a merge gate
Negative
- Adds another Composer
require-devdependency and related config/CI surface area to maintain - Without explicit agent/docs guidance, assistants may treat Infection like PHPStan and run it unexpectedly
- Informational comments can be ignored, so test-quality gains depend on voluntary follow-up
Neutral
- Blocking mutation thresholds and mandatory local/agent runs remain out of scope until revisited
- Exact pipeline wiring (when comments are posted, score thresholds if any, which suites are mutated) is not fixed by this thread and needs separate implementation detail