Phpunit Extensions Laravel Package

Product Decisions This Supports

• Build vs. buy vs. borrow for test tooling — the answer here is "none of the above." This is an archived (since 2017), 17-star, zero-dependent utility library. The decision it supports is a rejection with a documented rationale, not an adoption.
• Mutation testing roadmap — padraic/phpunit-extensions is the PHPUnit glue layer extracted for Humbug, Padraic Brady's mutation testing framework. If mutation testing is on the roadmap, the decision is Infection (Humbug's maintained successor), not this package. Adopting the extension library would buy the scaffolding without the product.
• Dependency hygiene and tech-debt triage — if this appears anywhere in a composer.lock, it is a removal candidate. The PM decision is whether to schedule removal now (cheap, zero dependents) or tolerate it until the next PHPUnit upgrade forces the issue.
• PHPUnit upgrade planning — the extension points this package targets (test listeners, mock helpers) were deprecated and then replaced by PHPUnit's Extension/bootstrap API. A dependency here is a hard blocker on modern PHPUnit, which cascades into PHP version support and CI image currency.
• Use cases it does not unlock — no CI reporting, no coverage merging, no mocking ergonomics worth a transitive dependency, no security posture. There is no user-facing feature you can ship on top of this that you could not ship faster by writing ~200 lines against current PHPUnit.

When to Consider This Package

Adoption criteria are effectively nil. The only defensible reasons to look at it are archaeological:

• Reproducing or auditing a 2015–2017-era Humbug build for compliance or forensic reasons.
• Reading it as a reference implementation of PHPUnit listener patterns before writing your own against the modern extension API.
• Forking it — the BSD-3-Clause license permits this — but the fork would be a rewrite, so the license is the only thing you'd actually inherit.

Look elsewhere immediately if any of the following are true, which for essentially all active products they are:

• You are on PHPUnit 7+ (or plan to be), or PHP 7.2+.
• You need a maintained dependency with a security-response path.
• You need vendor support, documentation, or an issue tracker that gets read.
• You want mutation testing as a capability rather than as plumbing — go to Infection directly.
• You need PHPUnit extension behavior — use PHPUnit's native extension API, which is where the ecosystem consolidated.

How to Pitch It (Stakeholders)

To executives: This is not a product capability, it's a dead utility library. It carries no license cost (BSD-3-Clause) and no strategic upside; its only real cost is the upgrade friction it creates if it ever enters our dependency graph. Recommendation: exclude it, and if mutation testing is a quality goal, budget for Infection — the maintained successor from the same lineage — instead.

To engineering: Archived since 2017, last release 2017-09-10, 17 stars, zero dependents, and built against a PHPUnit extension API that no longer exists. Its value was as Humbug's internal glue, and Humbug itself was superseded by Infection. The surface area is small enough that reimplementing the handful of listener/mock helpers you actually need against PHPUnit's current extension API is a day of work, and dropping the need entirely by adopting Infection is often zero work. Treat any existing reference as tech debt with a scheduled removal, not as a foundation.