Symfony Extension Laravel Package

Product Decisions This Supports

• Acceptance-testing strategy — the actual decision on the table. This package only matters inside the "keep Behat as our BDD/acceptance layer" branch. If the team is deciding between Behat and Pest/PHPUnit plus framework-native HTTP tests, this package is a data point for the cost and risk of the Behat branch, not a reason to choose it. It informs the decision; it does not decide it.

• Build vs. buy vs. vendor. The capability — boot a framework kernel per scenario, expose the service container to step definitions, isolate state between scenarios — is glue code. The first-party/community equivalent (friends-of-behat/symfony-extension) exists and is maintained. So the real decision is never "adopt short-edition/symfony-extension"; it is "vendor our own patch or migrate to the maintained upstream." Budget a spike, not a procurement.

• Framework-fit triage — and a hard no for Laravel. Despite being surfaced as a Laravel/PHP package, this is a Behat extension for Symfony full-stack apps. It assumes a Symfony kernel bootstrap and DI lifecycle. On a Laravel codebase its value is effectively zero: Laravel's testing stack (php artisan test, HTTP tests, container bindings) already covers the same ground without Behat. If a stakeholder is asking "can we use this in Laravel?", the PM answer is: no, and here is why — that is a decision worth recording.

• Dependency-hygiene policy. A concrete case for how the org treats archived, zero-star, zero-dependent packages in the test toolchain. Even non-shipping code needs an owner. This is a reusable rule to codify: archived + no dependents + no release cadence = fork obligation, not a dependency.

• Roadmap input for legacy Symfony/Behat surfaces. If any product area still runs a Behat suite against an older Symfony, this flags where migration budget is needed before a PHP or Symfony major version forces it. That is a scoped, time-boxed line item, not a platform initiative.

• Realistic use cases, if adopted at all: reusing existing Symfony services in step definitions, per-scenario kernel boot in a test environment, and HTTP-level acceptance tests against the app's front controller — for a Symfony application. None of these transfer to Laravel.

When to Consider This Package

• Only in a narrow legacy scenario: you already have a working Behat suite on an older Symfony, this fork carries a specific patch that upstream does not, and you cannot backport it. That is the entire qualifying condition.

• Adoption criteria if you proceed anyway: PHP/Symfony versions are pinned and stable; the code is test-only with a small blast radius; a named engineer owns the fork; the package is vendored or mirrored internally so it cannot vanish; and Composer resolution has been proven by a time-boxed spike against the real CI image.

• Look elsewhere when: the project is greenfield; there is no existing Behat investment; the stack is Laravel rather than Symfony; you need maintained support, security review, or a CVE response path; or policy forbids archived dependencies. In all of these — which is most cases — use the maintained FriendsOfBehat extension (Symfony) or Laravel-native testing (Laravel).

• Red flags to weigh: archived status, zero stars, zero dependents, no release cadence. There is no community to catch regressions and no upstream to escalate to. You are adopting unmaintained code you will own — treat it as a fork, never as a dependency. Also expect Composer conflicts against modern PHP 8.x and Symfony 6/7.

• Questions to answer before spending any time: Is the target actually Symfony, or is this being evaluated for Laravel? Which Behat/Symfony/PHP versions must be supported? What existing Behat suite depends on this, and what does replacing it cost? Who owns the fork?

How to Pitch It (Stakeholders)

• To executives (one paragraph): This is not a strategic dependency. It is small test-harness glue with zero adoption and no maintainer, and it targets Symfony, not our Laravel stack. Recommendation: no new adoption. If it already sits in a legacy codebase, contain it behind a pinned lockfile, assign an owner, and fund a short migration off it. The cost of doing nothing is a silent break on the next PHP/framework upgrade; the cost of migrating is days, not quarters.

• To engineering: It wires Behat to Symfony by booting the kernel and injecting the container into step definitions — behavior reproducible with the official maintained extension in roughly a day, and with Laravel-native tests for free on our primary stack. Carrying an archived fork of that glue is a worse trade than replacing it. Frame the work as a time-boxed spike: inventory existing features/contexts, stand up the maintained alternative on a branch, run the suite in CI, then delete the dependency.

• The ask: A small, time-boxed spike to migrate any remaining Behat suites, plus a written rule — archived packages with zero dependents do not enter the test stack without a named owner and a vendored copy. Add this package to the risk register if it is already in the codebase, and document the supported test harness so the next team does not re-litigate it.