Abstract Testframework Adapter Laravel Package

Product Decisions This Supports

• Quality-gate roadmap (mutation testing adoption): This package is the extension contract for Infection, the PHP mutation testing tool. A PM decision to add "mutation score (MSI) thresholds" to CI for a Laravel codebase runs through Infection; this adapter layer determines whether a new or non-standard test framework can participate. It does not matter on its own, but it is a gating dependency for the broader mutation-testing capability.
• Build vs buy for test-framework integration: If the team's test stack is standard (PHPUnit or Pest via the official adapter), this is a transitive dependency—no PM decision. If the team runs a custom or in-house test harness, or an unusual Pest/PHPUnit version, the "buy" option is: implement this abstraction rather than building bespoke mutation tooling or forking Infection's internals. That is a small, bounded engineering cost versus a large custom-tooling cost.
• Multi-framework standardization: Laravel shops commonly straddle PHPUnit and Pest. The abstraction (plus the HasSyntaxErrorDetection interface added in 0.5.0) lets one mutation-testing pipeline serve both, rather than maintaining two quality-gate configurations or exempting one stack from coverage.
• Use cases where it earns its place: adding mutation testing to a legacy Laravel app with a customized runner; piloting mutation testing before a Pest migration; producing defensible "our tests actually catch bugs" metrics for an engineering-health review; keeping CI signal clean when syntax errors in test output would otherwise be misreported as test failures.
• Use cases where it does not: any project that has not adopted Infection; teams using only the officially supported adapters; organizations requiring vendor SLAs or audited dependency trees.

When to Consider This Package

• Adopt (indirectly) when you are already running Infection on a Laravel/PHP codebase and either (a) use the stock PHPUnit/Pest adapters—in which case this arrives as a transitive dependency and simply needs to be version-compatible, or (b) need mutation testing to cover a test framework that has no official adapter, in which case extend AbstractTestFrameworkAdapter and implement the interfaces here rather than forking Infection.
• Consider deliberately when syntax errors in test output are a real source of noisy or misleading mutation results, and you want a consistent detection contract across frameworks instead of one-off parsing in each project.
• Look elsewhere when:
  • Infection is not in the stack—there is no standalone value here. It is an interface library, not a feature.
  • A single, officially supported test framework is used and is unlikely to change; the abstraction's benefit is theoretical.
  • Long-term vendor support, security auditing, or a published support policy is required. Signals are thin: ~25 stars, no dependents, a narrow release history, and a scope limited to interface churn (0.3.0 and 0.4.0 both shipped breaking changes; 0.4.0 introduced a required checkVersion() method). Recent releases indicate the project is alive, but this is maintainer-dependent infrastructure.
  • The team cannot absorb a breaking change in a dev-only dependency on short notice; every adapter consuming this contract is exposed to those BC breaks.
• Due diligence before committing: confirm which adapter your Infection version actually resolves, that the pinned versions are compatible with your PHP runtime (8.2+ support is not clearly evidenced), and that the package is still referenced by Infection rather than superseded by an in-repo implementation.

How to Pitch It (Stakeholders)

For executives: This is plumbing inside our test-quality tooling, not a product feature and not a strategic bet. Its only relevance is that it lets us turn on mutation testing—"do our tests actually catch bugs?"—and extend that signal across whatever test framework each team uses, without building custom tooling. Risk is low: dev-only dependency, no runtime or customer-facing surface, and no lock-in beyond the CI job it powers. Recommendation: approve it as part of a mutation-testing pilot; do not fund work around it absent a concrete need for a non-standard test framework.

For engineering: Treat infection/abstract-testframework-adapter as the contract layer you implement only if you are writing or maintaining an Infection adapter—for anything else it is a transitive dependency you pin and forget. If you do implement it: extend AbstractTestFrameworkAdapter for the shared prepare/execute/parse flow, override mapExitCode() and getAdditionalArguments() for framework specifics, implement hasSyntaxError() where syntax failures must be distinguished from test failures, and keep all framework internals inside the adapter. Two cautions worth stating up front: this package has no meaningful test suite of its own, so validate adapters against real suites in a separate project; and it has a history of breaking changes in minor releases, so pin versions and budget a small upgrade cost per Infection bump. If the work is not on the critical path to a mutation-testing gate, defer it.