Behat Chrome Extension Laravel Package

Product Decisions This Supports

• Test-infrastructure modernization: This package sits in the browser-automation layer of a PHP/Behat stack, so adopting it is a decision to standardize E2E testing on Chrome/Chromium (headless in CI) rather than on Selenium Grid or cloud device farms. That choice determines CI cost, flake rate, and how fast the team can ship customer-facing flows.
• Build vs. buy vs. borrow: It is a thin glue layer between Behat and Chrome via Mink. Building it in-house is not worth the effort; the real build-vs-buy decision is Behat+Chrome (this package) vs. Playwright/Cypress vs. a managed testing SaaS. This package is a "borrow" that keeps the existing Behat suite viable.
• Dependency-risk governance: v1.5.1 exists solely to resolve a Composer conflict with dmore/chrome-mink-driver 2.11.0. That tells you the package is version-coupled to its driver — a supply-chain and upgrade-sequencing item for teams with strict lockfile policies, and a signal that driver upgrades may require a coordinated bump of this extension.
• Roadmap inputs it informs: migration of legacy Behat suites, CI runner image changes (Chrome version pinning), and eventual retirement of the Behat layer if the org moves to a JS-native E2E framework.
• Not a product differentiator: Nothing here affects user-facing features. Treat it as enabling infrastructure — it should be tracked in platform/maintenance budget, not product roadmap commitments.

When to Consider This Package

Consider adopting (or keeping) it when:

• You already run Behat + Mink and want Chrome/Chromium as the browser under test without hand-rolling a session driver.
• You need headless Chrome in CI and want a maintained extension rather than a bespoke bootstrap.
• Your team is on the Sylius ecosystem (or a similarly Mink-based stack) and values alignment with upstream maintenance.
• You want a minimal, low-surface-area integration — this is not a framework, and its small footprint is the point.

Look elsewhere when:

• You are starting a new E2E suite from scratch — Playwright, Cypress, or Pest's browser testing are stronger defaults for a modern Laravel team; Behat's Gherkin overhead rarely pays for itself outside BDD-mandated organizations.
• You need cross-browser coverage (Safari, Firefox, real devices) — a Chrome-only extension will not get you there.
• You require vendor-backed SLAs or security guarantees — this is a community-maintained extension with a small contributor base (v1.5.1 is one external contributor's first PR).
• You are not on Composer/PHP for testing, or you have already moved browser testing out of the PHP process.

Risk note on v1.5.1: patch-level only — no API changes, no deprecations, no breaking changes. Upgrade risk is effectively nil, but confirm your dmore/chrome-mink-driver constraint resolves cleanly before locking. The absence of any other activity in this release is itself a signal: the package is in maintenance mode, not active feature development. Plan accordingly and avoid depending on it for anything beyond driver wiring.

How to Pitch It (Stakeholders)

For executives: This is a small piece of test plumbing, not a product component. The new v1.5.1 release is a compatibility fix — it removes a version conflict with its Chrome driver. There is no functional change, no security implication, and no migration work. Recommended action: take the patch in a routine dependency update; no roadmap or budget impact. The strategic point worth flagging is that our browser-testing stack is on a community-maintained PHP integration; it is cheap to keep and cheap to leave, and we should decide within the next planning cycle whether the Behat layer still earns its keep versus a JS-native alternative.

For engineering: v1.5.1 pins resolution against dmore/chrome-mink-driver 2.11.0 via a Composer conflict rule. Bump both together, run the Behat smoke suite against your pinned Chrome version, and verify the CI image. Expect the package to move slowly — treat it as frozen infrastructure and budget for eventual replacement rather than waiting on upstream features. If you are greenfielding E2E coverage, this should not be your first choice; if you are sustaining an existing Behat suite, it remains the lowest-friction option.