Phpunit Slow Test Detector Laravel Package

Product Decisions This Supports

• CI/CD Optimization: Accelerate test suite execution by identifying and addressing slow tests, reducing CI feedback loops and improving developer productivity.
• Quality Assurance (QA) Roadmap: Integrate into a broader test performance initiative, aligning with goals to improve test reliability and maintainability.
• Build vs. Buy: Buy—this is a lightweight, open-source solution that eliminates the need to build custom slow-test detection logic from scratch.
• Use Cases:
  • CI/CD Pipeline Bottlenecks: Prioritize optimization efforts by flagging slow tests that disproportionately impact build times.
  • Test Suite Health: Proactively monitor test performance to prevent regression in execution speed.
  • Onboarding/Developer Experience: Highlight slow tests to new contributors, reducing friction in test suite contributions.
  • Performance Budgeting: Enforce explicit thresholds for test execution time (e.g., "no test should exceed 500ms") to maintain predictable CI runs.

When to Consider This Package

• Adopt if:

  • Your PHP/Laravel project relies on PHPUnit and has a growing test suite (e.g., >500 tests) where execution time is becoming a bottleneck.
  • CI/CD pipelines are flaky or slow, and test performance is a known pain point.
  • You lack built-in observability into test execution times (e.g., no native PHPUnit slow-test reporting).
  • Your team prioritizes test maintainability and wants to enforce performance standards for tests.
  • You’re using PHPUnit v6.5.0–v13.0.0 (compatibility is a hard requirement).

• Look Elsewhere if:

  • Your test suite is small or fast (<100 tests, <10s total runtime), making slow-test detection unnecessary.
  • You’re using alternative testing frameworks (e.g., Pest, Codeception) that already include performance metrics.
  • Your CI system has native slow-test detection (e.g., GitHub Actions’ built-in timing tools) or you’re using a custom solution already.
  • You need advanced profiling (e.g., memory usage, CPU spikes) beyond execution time—consider Xdebug + Blackfire or Tideways.
  • Your team lacks buy-in for test performance standards (this tool enforces discipline, not just observation).

How to Pitch It (Stakeholders)

For Executives:

"This package is a low-effort, high-impact way to fix a hidden CI/CD bottleneck. Slow tests silently inflate our build times, delaying feedback for developers and increasing operational costs. By automatically flagging tests that exceed our performance thresholds (e.g., 500ms), we can cut CI runtime by 20–30% and reallocate engineering time to higher-value work. It’s like a ‘linter for test speed’—no code changes required, just plug-and-play."

Ask:

• "Would you prioritize reducing CI feedback loops as a 2024 QA goal?"
• "How much time do we lose weekly to slow test suites?"

For Engineering/DevOps:

*"This is a zero-configuration way to enforce test performance standards. It integrates directly into PHPUnit and surfaces slow tests in your existing workflow—no new tools or dashboards needed. Key benefits:

• Automated alerts: Catch slow tests before they break CI.
• Actionable data: Prioritize refactoring based on real metrics (e.g., ‘TestX is 10x slower than the median’).
• Future-proof: Works with all PHPUnit versions we support (v6.5–v13).

Implementation:

1. Add composer require --dev ergebnis/phpunit-slow-test-detector.
2. Configure thresholds in phpunit.xml (e.g., maximum-duration="500").
3. Run tests—it’ll auto-report slow tests.

Trade-offs:

• No false positives (it’s deterministic).
• Doesn’t replace profiling tools like Blackfire—just complements them for test-level performance."

Ask:

• "Should we start with a 500ms threshold, or align it with our CI timeout limits?"
• "Who owns optimizing the top 5 slowest tests after we identify them?"