Testbench Dusk Laravel Package

Product Decisions This Supports

• Whether "browser-verified" becomes a release criterion for our packages. This package makes it feasible to run Laravel Dusk against a package in isolation (via a Testbench-provided skeleton served through a local php -S DuskServer), rather than only in a full application. That converts a vague quality aspiration into a concrete, automatable gate for any package that ships Blade views, Livewire components, published assets, routes, or JS.
• Build vs. buy for package-level E2E infrastructure. Standing up Dusk against a package normally means hand-rolling an application skeleton, service provider bootstrapping, asset publishing, and a web server lifecycle. This package encodes that plumbing (plus beforeServingApplication() / afterServingApplication() hooks, and a package:dusk-purge command with --pretend) and is MIT-licensed. Default recommendation: buy, unless we already have a hardened internal harness.
• Roadmap sequencing and upgrade cadence. Releases are tightly coupled to Testbench and Testbench Core minors and to Laravel majors (v7 → v11, with v11 adding Laravel Framework v13 and Dusk 8.3.5+; v10.2.0 added PHPUnit 12 support). Adopting this package effectively commits us to tracking Testbench majors, so it belongs on the platform-upgrade roadmap, not as a one-off dev dependency.
• Test strategy allocation. Decides where browser tests sit relative to feature/HTTP tests: keep the bulk of coverage in Testbench feature tests, and reserve Dusk for the narrow set of behaviors that only manifest in a real browser (asset publishing, compiled Blade directives, middleware/session flows, JS-driven interactions).
• Risk register entry for a single-maintainer dependency. Zero dependents and low community validation, plus a README that still self-describes as "in early development" after transfer from Konsulting Ltd, mean this should be classified as acceptable but non-strategic — fine to depend on, not fine to build a product differentiator on.

When to Consider This Package

Adopt when:

• We are developing a Laravel package, not an application, and already use orchestra/testbench for its test suite.
• The package ships a user-facing surface: Blade components/views, Livewire or Filament-style components, published CSS/JS, registered routes or middleware.
• CI can provision a headless Chrome/Chromedriver and tolerate the extra minutes and flake surface.
• We can pin to a specific Testbench major and accept a maintenance task each time Laravel or Testbench bumps.
• We need regression coverage for bugs that historically only appeared in a browser ("passes in PHPUnit, broken in the browser").

Look elsewhere when:

• The product is an application — use laravel/dusk directly; this package exists to compensate for the absence of an app skeleton.
• Coverage is achievable at the HTTP/feature level — plain Testbench + PHPUnit is faster, cheaper, and far less flaky.
• We need cross-browser, mobile viewport, or visual-regression coverage — Playwright/Cypress, or Pest's Playwright-backed browser testing, are stronger fits and reduce CI maintenance.
• The package has no UI surface (a client SDK, an API-only integration) — the browser harness adds cost with no signal.
• We cannot absorb a single-maintainer dependency or cannot commit to version-ladder maintenance.

Watch item: the DuskServer pipe-fill hang has been re-fixed across multiple release lines (v9.20.0, v10.11.0, v11.3.0, v7.58.0). Budget for occasional CI hangs and treat timeouts/retries as a first-class configuration decision, not an afterthought.

How to Pitch It (Stakeholders)

For executives: We ship Laravel packages whose UI is our visible product surface, but today we can only test them at the HTTP layer — the class of bug that reaches customers is the one that only shows up in a real browser. This open-source, MIT-licensed helper lets us run real browser tests against our packages without maintaining our own test application, at the cost of a small amount of CI infrastructure and a routine dependency upgrade each time we move Laravel versions. It is a cheap de-risking of package releases, not a strategic bet: the project is actively released and version-synced with Laravel and Testbench, but it is a narrow, single-maintainer tool with a small user base, so we should adopt it as a testing utility and avoid coupling product architecture to it.

For engineering: orchestra/testbench-dusk gives us Dusk against a Testbench skeleton — it boots our package, serves it locally, and exposes beforeServingApplication() / afterServingApplication() hooks plus package:dusk-purge for cleanup. It tracks Testbench and Testbench Core minors aggressively, so pin versions and expect an upgrade task per Laravel major (v11 line supports Laravel 13 / Dusk 8.5). Recommended shape: keep feature tests as the primary safety net, add a thin Dusk suite for asset publishing, Blade/Livewire rendering, and JS interactions, run it headless in CI on a separate job, and quarantine flaky specs rather than retrying indefinitely. Note the recurring DuskServer pipe-hang fixes — set explicit server timeouts.