Skip to content
TilloTech Docs

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-dev dependency
  • 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-dev tool 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-dev dependency 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