Phpunit Slow Test Detector Laravel Package

Product Decisions This Supports

• Test-suite performance investment: Quantifies which tests exceed a configurable duration threshold, helping decide whether to refactor, split, quarantine, or delete slow tests instead of guessing from total CI time.
• CI cost and release-velocity tradeoffs: Identifies whether slow tests are a meaningful contributor to pipeline duration, informing decisions on runner sizing, parallelization, test sharding, caching, or build-minute budgets.
• Technical-debt prioritization: Ranks slow tests by duration and exposes data-provider cases that individually cross the threshold, making test performance work concrete and backlog-ready.
• In-PR visibility of test debt (new in 2.27.0): Slow tests can now be emitted as GitHub Actions annotations, surfacing offenders directly in pull-request checks rather than only in console logs. This makes “fix the slow test you just touched” a practical review-time conversation, while remaining informational rather than a blocking gate.
• Build vs. buy for test observability: Offers a low-integration PHPUnit extension versus building a custom listener or parsing JUnit output; useful when the team wants quick visibility without a full APM/profiling platform. The 2.27.0 extraction of report printing into a dedicated Printer marginally raises the ceiling on customizing/integrating output, though it is not a public plugin API commitment.
• Developer-experience roadmap: Supports decisions to reduce local feedback loops, set team norms around maximum test duration, and improve PHP/Laravel developer productivity.
• Release-process quality signals: Provides per-run evidence that can inform release readiness discussions; it is best used as visibility, not as a hard quality gate unless paired with additional CI enforcement.
• Tooling standardization: Can be evaluated as a lightweight, dev-only standard across Laravel/PHP services that use PHPUnit — with the caveat that 2.27.0 raises the PHP floor and shifts PHPUnit 13 configuration details (see below).

When to Consider This Package

Consider it when:

• The product is a Laravel/PHP application or service using PHPUnit 6.5 through 13.x, running on PHP 7.4 or newer. Version 2.27.0 drops support for PHP 7.0, 7.1, 7.2, and 7.3; services still on those runtimes (older Laravel 5.x/6.x-era apps) must pin an earlier release and should treat that as a maintenance liability.
• The test suite is large enough, or CI feedback slow enough, that “which tests are slow?” is a recurring engineering question.
• CI runs on GitHub Actions and you want slow tests visible in the PR diff/checks. 2.27.0 adds GitHub Actions annotations, which is the highest-leverage change for reviewer workflow; teams on GitLab CI, Jenkins, or Buildkite still get the console report but not this benefit.
• The team wants a low-friction, dev-only diagnostic: composer require --dev, add an extension entry to phpunit.xml, configure maximum-duration and maximum-count, and read the report.
• You need targeted slow-test visibility without adopting a full observability platform such as Blackfire, Tideways, or APM tooling.
• You are willing to validate compatibility in your exact stack, especially if using Pest or customized PHPUnit configuration.

Look elsewhere or defer adoption when:

• The suite is already small and fast, or CI duration is dominated by setup, database, browser, or infrastructure work rather than test execution.
• You need historical trend dashboards, cross-run analytics, memory profiling, query analysis, or production APM; this package reports per run, not as a long-term metrics platform.
• You cannot add a dev dependency or need guaranteed vendor support/SLA. The package is MIT-licensed and mature in documentation/releases, but adoption is niche (roughly 151 stars, 0 dependents), so maintainer and ecosystem risk should be assessed.
• You need enforcement rather than reporting. GitHub Actions annotations improve visibility but are still advisory; treat them as an input to CI policy, not a complete quality gate.
• Your PHP runtime is below 7.4, or your PHPUnit version or test runner is outside documented compatibility, or your organization requires a higher-adoption tool with broader community validation.

How to Pitch It (Stakeholders)

For executives: This is a low-cost, dev-only PHPUnit extension that makes slow tests visible. It does not ship to production and does not change application runtime behavior. The business case is faster developer feedback, more efficient CI spend, and better prioritization of test-suite technical debt. The latest release makes slow tests appear as annotations directly in GitHub pull-request checks, which lowers the cost of acting on them during normal review. Approve a time-boxed pilot in one Laravel/PHP repository, measure CI duration and slow-test count before and after, then decide on broader rollout.

For engineering: Adoption is simple: install as a dev dependency, register the extension in phpunit.xml, and set a duration threshold and report limit. It produces a ranked list of slow tests, including data-provider cases, which gives the team actionable targets for refactoring, parallelization, or quarantine decisions. In 2.27.0 the report is rendered through a new Printer, line wrapping and trailing-newline output were fixed, and GitHub Actions annotations were added — expect small cosmetic changes to log output, so avoid snapshot-testing the report text. Note the PHP floor is now 7.4 (7.0–7.3 support dropped) and the deprecated cacheResult attribute was removed for PHPUnit 13 configurations; check your phpunit.xml if you are on or moving to PHPUnit 13. Pin the version, review the changelog, and verify behavior in the project’s exact PHPUnit/Pest setup.

Risk framing: The package is focused and well-documented, but niche, and 2.27.0 is a good reminder that it moves with upstream PHP/PHPUnit support windows — plan for periodic version bumps driven by runtime upgrades. Mitigate by piloting in one repository, avoiding a production dependency, pinning the version in composer.json, and keeping a fallback of JUnit timing extraction or CI-level duration reporting. Success criteria should be concrete: reduced median PR pipeline time, fewer tests above the threshold, and measurable CI-minute savings within two sprints.