Behat Bundle Laravel Package

Technical Evaluation

Architecture fit. The package is a Symfony bundle that sits entirely in the testing tier — it has no production runtime footprint and injects no service into the application container beyond test-env registration. Its actual value is a thin layer of Behat subcontexts over MinkContext: automatic screenshots on failed steps, an Ajax-settled wait (jQuery.active-style), and convenience assertions such as assertPageContainsText(). That means the "fit" question is narrow: it only applies if we run Symfony + Behat 3 + Mink + a Selenium-backed driver. If our acceptance layer is Pest/PHPUnit + Laravel Dusk, Cypress, or Playwright, architectural fit is effectively zero and the decision is trivial — do not adopt.

Integration feasibility. Low to moderate. The bundle was written against Behat 2.x/3.x-era extension APIs and pre-Flex Symfony bundle conventions (manual AppKernel/bundles.php registration, older DI compiler passes). Composer will be the first blocker: the behat/behat and symfony/* constraints almost certainly cap below what a current stack resolves to, forcing --ignore-platform-reqs or a fork. Even after resolution, PHP 8.2/8.3 will surface signature and deprecation errors in the context base classes.

Technical risk. High, and concentrated in three places:

• Abandonment. Last release 2014-04-05 — eleven years. No security feed, no maintainer response path, no PHP 8 support.
• Zero dependents. No downstream community exercising it means no de facto compatibility signal and no one to share fork maintenance with.
• Superseded capability. Screenshot-on-failure and Ajax waiting are now covered by maintained options (FriendsOfBehat/MinkExtension, behat-screenshot-style extensions, dmore/behat-chrome-extension, or the built-in network-idle semantics of Playwright/Cypress). The bundle's differentiator has been commoditized.

Key questions.

1. Which acceptance-test stack are we actually committing to for the next 24 months — this determines whether the package is even relevant?
2. Are we willing to own a fork indefinitely, or is this a one-time capability harvest?
3. What is the cost of reimplementing screenshot-on-failure + Ajax-wait in our own context classes versus forking? (Likely 100–200 LOC.)
4. Does our CI artifact pipeline already store screenshots, or does that need to be built regardless?
5. Is there any Kunstmaan CMS dependency in the estate that creates a false sense of alignment?

Integration Approach

Stack fit. Only viable in an existing Symfony application already running Behat 3 + Mink + Selenium/ChromeDriver. It carries no value for Laravel-native testing and should not be introduced to greenfield projects.

Migration path. Do not adopt as a dependency. Treat it as a reference implementation: read the three contexts, extract the behaviors, and port them into first-party context classes in our own test support namespace. This eliminates the Composer constraint fight, the abandonment risk, and the ownership ambiguity in one step.

Compatibility. Pin expectations explicitly before any spike: PHP version, Behat major, Mink driver, Symfony major. Verify the bundle's composer.json constraints resolve against our lockfile; expect them not to. Confirm bundle registration works under Flex (config/bundles.php) or accept that a manual kernel edit in the test env is required.

Sequencing.

1. Week 0 — Decide. Confirm acceptance-test framework commitment. If not Behat, close the evaluation.
2. Week 1 — Spike. Branch-only install attempt on current PHP. Timebox to two days. Success criterion: a failing step produces a screenshot artifact and an Ajax wait resolves reliably in CI.
3. Week 1–2 — Fallback path. If the spike fails (expected), reimplement: a @AfterStep/@AfterScenario hook for screenshot capture, a wait helper polling jQuery.active or driver-level network idle, and a text-assertion wrapper.
4. Week 2 — Wire CI. Screenshot directory must be a published artifact with retention policy.
5. Week 3 — Document and close. Record the decision and rationale; add the package to the "evaluated, not adopted" register so the question is not reopened.

Operational Impact

Maintenance. Adoption converts a third-party dependency into a permanent fork obligation. There is no upstream to rebase against, so every PHP or Behat upgrade becomes our problem to solve. Budget for at least one engineer-day per major toolchain upgrade.

Support. No vendor, no maintainer SLA, 16 stars of community. Internal ownership must be assigned to the QA/platform team explicitly; otherwise the contexts rot silently until a PHP bump breaks the whole suite.

Scaling. The bundle itself does not scale concerns — Selenium Grid topology does. But the screenshot-on-failure behavior has a real scaling cost: parallel CI shards writing screenshots require per-shard artifact directories and collision-safe naming, or artifacts get overwritten. Ajax waiting is per-test wall-clock time; a naive fixed sleep or coarse poll interval multiplies across thousands of scenarios and becomes the dominant suite runtime.

Failure modes.

• Silent screenshot loss if the target directory is unwritable or relative-path resolution differs between local and CI — tests fail, artifacts absent.
• Flaky Ajax waits — jQuery.active misses fetch/XHR and non-jQuery stacks entirely, producing intermittent false passes or timeouts.
• Hook ordering conflicts with other Behat extensions, particularly when multiple extensions register @AfterStep.
• Deprecation noise to hard failure on PHP 8 upgrades, breaking the suite wholesale rather than incrementally.
• Composer drift where a transitive constraint change silently drops the bundle from the test build.

Ramp-up. Low for engineers already fluent in Behat/Mink (the API surface is small and idiomatic). The real ramp-up cost is organizational: explaining to the team why an unmaintained 2014 package is in the dependency tree, and defending the fork in future security and upgrade reviews. That soft cost typically exceeds the reimplementation cost within the first quarter.