Phpunit Speedtrap Laravel Package

Product Decisions This Supports

• Test-suite performance roadmap: Provides concrete, per-test timing data that turns "our CI is slow" from a vague complaint into a ranked backlog of offenders, letting you sequence optimization work by actual impact rather than intuition.
• CI cost and cycle-time decisions: Slow tests are a direct driver of developer wait time and CI minutes spend. SpeedTrap evidence supports decisions like sharding the suite, moving slow integration tests to a nightly job, or justifying investment in parallelization infrastructure.
• Build vs. buy vs. instrument: Weigh a nearly zero-cost, MIT-licensed package against building custom timing instrumentation into our test harness or buying a broader APM/observability product. For a PHP/Laravel team, this is usually a "buy" (adopt) with negligible switching cost.
• Engineering standards and definition-of-done: Enables a team policy such as "no new test exceeds 500ms without a documented reason," enforced socially via the report and technically via the ignore list. This is a lightweight guardrail decision, not a tooling project.
• Prioritizing refactoring work: A slow test is often a symptom — hitting a real database, un-factored service container setup, sleep-based waits. The reported offenders become a defensible input to tech-debt triage.
• Adoption/rollout decision: Because it is a transparent PHPUnit listener, the decision is reversible in one config line — low blast radius, suitable for a trial on one team or one service before standardizing.

When to Consider This Package

Consider adopting when:

• The stack is PHP/Laravel and the team runs PHPUnit (not Pest-only, though Pest sits on PHPUnit and may still work depending on version).
• CI wall-clock time or local test feedback time is a recurring complaint, and nobody can name the slowest tests.
• The suite is growing and you want a cheap early-warning mechanism before performance decay becomes structural.
• You want a zero-runtime-production-risk tool: it affects only the test process, never application code or end users.
• You need a low-effort input to a quarterly engineering-efficiency or developer-productivity initiative.

Look elsewhere or proceed with caution when:

• PHPUnit 10+ is in use. The legacy listener API this package targets was removed/reshaped in modern PHPUnit; the last release is 2021-05-03, so verify compatibility on your exact PHPUnit version before committing. This is the single biggest adoption risk and should be spiked in a branch first.
• The team already has coverage from a broader platform: CI providers' built-in slow-test reporting, PHPUnit's own --log-junit / teamcity output parsed by CI, or full APM/tracing tooling. Duplicating overlapping tooling adds noise.
• The suite is small or fast enough that the signal is not actionable.
• The suite is already fast but slow in aggregate due to volume — SpeedTrap reports individual offenders, not aggregate breakdown. Sharding/parallelization analysis may be the better lever.
• You require actively maintained dependencies with a security/SLA guarantee; an unmaintained 2021 package may fail an internal dependency policy even if functionally fine.
• You want deep analytics (trends over time, historical dashboards). This is a per-run report, not a metrics store — pair it with CI artifacts or a dashboard if trend data is the actual requirement.

How to Pitch It (Stakeholders)

For executives (one paragraph): Developer time is our most expensive and least elastic resource, and slow test suites tax it on every commit. This is a free, MIT-licensed, single-line addition to our PHP test runner that names exactly which tests are slow, so we stop guessing and start fixing the handful of tests that actually cost us hours. It carries no production risk — it never touches the running application — and it is removable in one config change. The realistic outcome is measurable CI cycle-time reduction and lower CI spend, with the main caveat being a compatibility check against our current PHPUnit version that engineering can validate in under a day.

For engineering leadership:

• Cost: zero license cost, roughly an hour of setup, near-zero ongoing maintenance.
• Risk: contained to the test pipeline; the one real risk is the package's 2021 vintage against modern PHPUnit — treat as a spike, not a commitment, until verified.
• Ask: approval for a timeboxed trial (one sprint, one representative repo) with a before/after CI duration number as the success criterion.
• Exit criteria: if the report does not surface actionable offenders or the compatibility spike fails, we drop it and lose one engineer-day.

For the engineering team (the practical framing): Add the listener, set a threshold that matches our current median test time so the report is noisy-but-honest at first, then ratchet it down as we fix offenders. Maintain an explicit ignore list with a required comment for anything intentionally heavy, so the report stays trustworthy and people keep reading it. The real win is not the tool — it is the norm it makes enforceable: "your new test does not get to be the slow one."