Behat Laravel Extension Laravel Package

Product Decisions This Supports

• Build vs. buy for acceptance testing: The package answers a narrow, real question — "can we drive Laravel functional tests from Gherkin?" — for a very low price (MIT, one composer require). It is the cheapest way to validate whether BDD-style acceptance testing has stakeholder pull before committing engineering time to a custom harness.
• Feature definition and "done" criteria: By letting business-readable Given/When/Then scenarios execute against the real Laravel app, it turns acceptance criteria into executable, regression-guarded artifacts. That supports PM decisions on scope sign-off and release readiness, not just code quality.
• Roadmap prioritization for test infrastructure: A small, proven extension can justify a short discovery spike ("does BDD pay for itself here?") instead of a multi-sprint test-framework initiative. If scenarios are written by PM/QA and pass, that's evidence to fund more; if only engineers write them, it's a signal the value is low and the effort should go to plain feature tests.
• Stakeholder communication and audits: Gherkin scenarios double as living documentation of business rules, useful for regulated or client-facing engagements where "show me the acceptance test for that requirement" is a sales or compliance question.
• Use cases it fits: legacy Laravel applications already running Behat; teams with QA analysts who write scenarios; migration projects where behavior must be pinned before refactoring; contract/consulting work where scenario files are a deliverable.
• Not supported: it is not a browser automation decision — it does not replace Dusk/Playwright for JS-heavy UI. Treat it as an HTTP/application-layer acceptance layer, which bounds where the PM should claim coverage.

When to Consider This Package

Adopt or trial it when most of these hold:

• The team already uses Behat (or has committed to Gherkin) and needs Laravel bootstrapped inside step definitions — the extension's core job is exactly this: application container plus convenience contexts/traits for requests, database transactions, and assertions.
• The application runs a legacy stack (PHP 7.x era, Laravel 5.x/6.x). The last release in February 2018 means modern Laravel (8/9/10/11) and PHP 8+ compatibility is unproven and unlikely; verify with a one-day spike before promising anything.
• There is a non-engineer author for scenarios. Without that, Behat adds a translation layer over PHPUnit feature tests with little marginal value.
• You can absorb maintenance risk: expect to fork or vendor the extension, pin versions, or replicate its ~small surface area internally. Budget a maintainer, not just an install.
• Acceptance tests are HTTP/application-level, not JS-driven.

Look elsewhere when:

• You are on a current Laravel version or PHP 8+ — prefer Laravel's built-in HTTP feature tests, Pest, or Codeception (which has an actively maintained Laravel module), or a thin in-house Behat extension.
• You need browser/UI acceptance — Laravel Dusk or Playwright.
• Your organization requires actively maintained dependencies, security patching, or vendor support — the 2018 release date is a hard blocker for procurement.
• The team is small and PHP-native — plain PHPUnit/Pest feature tests deliver most of the regression value at lower ceremony; BDD's cost is real (scenario maintenance, glue code, slower suites).
• You want parallelization, CI reporting, or modern tooling out of the box — check the ecosystem rather than assuming this package provides it.

How to Pitch It (Stakeholders)

To executives: This is a low-cost, MIT-licensed bridge that lets us describe acceptance criteria in plain English and have them automatically verified against the actual application — so "done" is demonstrable and regressions are caught before release. It's a tactical experiment, not a platform commitment: a one-to-two week spike, no license spend, and a clear kill criterion if scenarios aren't being written or read by non-engineers. The main caveat is that the library hasn't been released since 2018, so we'd validate compatibility with our Laravel version first and be prepared to own a small fork rather than depend on upstream.

To engineering: It boots the Laravel container inside Behat and supplies contexts/traits for HTTP calls, database transactions, and assertions, so step definitions stay thin. Realistically it targets an older Laravel/PHP generation — treat it as a reference implementation and a fast start, then expect to fork, pin, or replace with a few hundred lines of our own extension. We should agree upfront on who owns it and on a CI budget for a slower acceptance suite. If we're already on a modern Laravel, the honest recommendation is Pest/PHPUnit feature tests plus, only if the business genuinely wants Gherkin, a minimal homegrown Behat extension modeled on this one.