friends-of-behat/performance-extension
FriendsOfBehat PerformanceExtension adds performance monitoring to Behat, measuring scenario runtimes and enforcing time limits so slow tests or regressions fail early. Useful for PHP teams wanting performance checks alongside behavioral tests.
Architecture fit. The package is a Behat extension, not a Laravel package — it plugs into Behat's extension/hook system via behat.yml and alters how scenarios/processes are executed to cut wall-clock suite time. Laravel has no first-party Behat integration, so any adoption implies a second undocumented dependency (laracasts/behat-laravel-extension or a hand-rolled FeatureContext bootstrapping the framework). The stack fit is therefore indirect and multi-layered: Laravel → Behat → this extension. That is a weak fit for a modern Laravel codebase whose testing gravity is PHPUnit/Pest.
Integration feasibility. Low. The 2016 release predates PHP 7.2+ strictness, PHP 8 union types/enums, and multiple Behat major-line changes to the extension API. Its stated premise — "features available only for newer PHP versions" — is now obsolete, since whatever PHP 7 optimizations it exploited are subsumed by opcache preloading, PHPUnit/Pest parallel runners, and modern Behat releases. Expect version-constraint conflicts against Laravel 10/11 (PHP 8.2+) before a single test runs.
Technical risk. High, concentrated in abandonment: archived repo, last release 2016-11-02, 0 dependents, no security response path, no CI against current PHP. Parallel/fork-based execution is inherently stateful — Laravel's container, database transactions, queues, and cache are process-local, and a 2016-era extension cannot know about RefreshDatabase, connection-pooling, or Sail. Silent data races and non-deterministic flakes are the likely failure signature.
Key questions.
Stack fit. Poor as a direct dependency. Treat it as a reference implementation, not a component. The value it once provided — parallel Behat execution — is now served by maintained tooling (Pest's --parallel, ParaTest for PHPUnit, CI matrix sharding, or a maintained Behat parallel extension).
Migration path. Do not migrate to this package. If the team is on Behat today, the path is: (1) inventory current Behat suite runtime and flake rate, (2) benchmark a maintained parallel runner or CI sharding against it, (3) only if neither suffices, evaluate a vendor fork of this extension pinned to a modern PHP constraint. For a Laravel-native team, the realistic path is retiring Behat in favor of Pest, which removes this dependency class entirely.
Compatibility. Assume incompatible until proven otherwise: PHP constraint likely ^7.0-era, Behat API surface likely 3.x-era, no composer.json support for PHP 8.2/8.3 or Behat 3.13+. A spike should begin with composer why-not and a throwaway PHP 8.2 container before any architectural commitment.
Sequencing. (1) Confirm the business driver (CI duration SLO, developer feedback loop). (2) Spend no more than one engineer-day on an install spike in a scratch branch. (3) If the spike fails — the expected outcome — document the rejection and adopt the maintained alternative. (4) If it succeeds, fork, pin, and add a CI job that exercises the fork against the current PHP/Laravel matrix before merging.
Maintenance. Effectively total ownership from day one: archived upstream, no issue triage, no patches, no security advisories. Budget fork maintenance, PHP-version bump work, and Behat-upgrade work as recurring headcount cost, not a one-off.
Support. No maintainer, no community (0 dependents means essentially no field-tested usage to draw on). Internal escalation path is "the engineer who forked it." That is a bus-factor-1 risk on a non-core test-infrastructure component.
Scaling. The extension's only reason to exist is parallelism, and parallelism is exactly where Laravel test suites break first — shared databases, seeded fixtures, Redis/queue collisions, filesystem races. Scaling the suite means scaling these hazards alongside it, with no upstream fixes forthcoming.
Failure modes. Non-deterministic test failures that erode trust in CI; fork/pcntl unavailability on Windows and some containers; file-descriptor and socket exhaustion under high worker counts; silent no-op behavior if the extension quietly fails to hook under a newer Behat; and the classic decay pattern where a stale dependency blocks a PHP or Laravel upgrade for the whole repo.
Ramp-up. Low to use, high to own. Engineers familiar with Behat can wire it in quickly; engineers who must debug a 2016 fork's interaction with PHP 8 and Laravel's container will burn days. The dominant ramp-up cost is not this package but Behat itself, which is outside most Laravel teams' muscle memory — a strong argument for spending the effort on Pest parallelization instead.
How can I help you explore Laravel packages today?