Dusk Laravel Package

Product Decisions This Supports

• Roadmap sequencing for the quality/testing layer. Dusk answers "do we invest in an end-to-end/browser test capability this quarter, or push it a cycle?" It is a low-cost, first-party way to put a real browser in front of revenue-critical Laravel journeys (signup, login, checkout, billing, admin flows) without standing up a separate QA toolchain.
• Build vs. buy for E2E tooling. Buying here costs zero license dollars (MIT) and zero new languages: tests are PHP, written with PHPUnit or Pest, and run alongside the existing suite. The real cost is CI minutes plus the ongoing chore of keeping a Chromium/ChromeDriver binary in the pipeline — a budgetable, non-strategic cost rather than a platform commitment.
• Where Dusk sits in the test pyramid. This package supports the decision to keep business logic in fast HTTP/feature tests and reserve Dusk for a short list of critical user journeys (roughly 5–15 flows). That is a scoping decision a PM can own: agree the journey list, cap the suite, and refuse to let Dusk become the default home for every new test.
• Release-gating policy. Dusk enables a concrete gate choice: critical-path smoke suite on every release candidate vs. nightly-only regression runs. It also supplies the artifacts needed to make that policy workable — screenshots, console logs, and page source captured on failure, plus Page Objects and components so a failing test points at a screen, not a line of selectors.
• Staffing and skills planning. A PHP-only browser test stack means existing backend engineers can own E2E coverage; there is no need to hire JS/QA-automation specialists or add Node/Python to CI purely for testing.
• Framework upgrade planning. Dusk's release history tracks new Laravel and PHP versions (Laravel 13, PHP 8.5, PHPUnit 12.2, Pest 3 are all covered in recent changelogs). That makes it a low-risk dev dependency when scheduling a major Laravel/PHP upgrade — but it also means the upgrade plan should sequence the dev-dependency bump explicitly rather than assume it, since support for new framework majors lands in dedicated releases (e.g., "Supports Laravel 13" shipped as its own version).
• Front-end replatform risk assessment. Because Dusk is Chromium-centric and server-rendered-Laravel-friendly, the depth of Dusk investment should be inversely proportional to how soon you plan to rewrite the UI as a SPA. Pair the decision with the front-end roadmap so you don't fund a suite the next platform drops.
• Reading the adoption signals correctly. Low package-level "dependent" counts and a modest star count are misleading for a dev-only, first-party Laravel tool: applications consume it, not other packages, and it is opt-in rather than bundled. Do not treat these numbers as a maturity or abandonment signal — the changelog cadence and version-tracking releases are the better evidence.

When to Consider This Package

Adopt Dusk when most of these hold:

• The product is a Laravel application with server-rendered views (Blade, Livewire, Inertia with modest client-side logic), where the value is in flows rather than component behaviour.
• You can name 3–15 revenue- or compliance-critical journeys worth guarding end to end, and those flows involve real form submission, redirects, sessions, cookies, or third-party redirects that HTTP-level tests cannot faithfully cover.
• The team is PHP-first and you want tests to live in the same repo, review process, and CI job graph as everything else.
• You want no JDK or Selenium install and are content with the bundled standalone ChromeDriver (or can supply a Selenium driver yourself).
• You have, or will build, CI capacity for a browser — headless Chrome on the runner or a container image — and a documented policy for flaky tests (quarantine, retry-once, owner).
• You need debuggable failures more than exhaustive coverage: screenshots, console logs, and page source captured automatically are worth more to a small team than raw assertion count.

Look elsewhere, or defer, when:

• The UI is a heavy SPA or a native mobile app; Playwright or Cypress will be the better fit for component-level mocking, network interception, and the JS ecosystem the front-end team already lives in.
• A cross-browser or device matrix is a hard requirement (Safari, Firefox, real devices, mobile viewports at scale). Dusk is Chromium-first; a commercial grid is the honest answer.
• The team has already standardised on Playwright/Cypress. Adding Dusk creates a second browser stack, second CI dependency set, and split ownership — a net negative even though the package itself is cheap.
• You need visual regression, rich network mocking, or performance/budget assertions as first-class capabilities rather than bolt-ons.
• The suite would need to be large and fast. Dusk is comparatively slow per test and its parallelism/sharding story is thinner than dedicated runners; if you expect hundreds of browser tests, that's a tooling mismatch, not a Dusk flaw.
• No one owns it. The most common failure mode is not technical — it is a suite that nobody triages, which then gets skipped and quietly deleted. Without a named owner and a CI budget line, don't adopt.

How to Pitch It (Stakeholders)

For executives (one paragraph): Laravel Dusk is a free, officially maintained browser-testing package for our Laravel application. It lets us automate the handful of user journeys that directly touch revenue and trust — signup, login, checkout, billing, account changes — and run them automatically before every release, so regressions are caught by the pipeline instead of by customers. There is no licence cost and no new technology stack: the tests are written in PHP by our existing engineers and run in our existing CI. The cost is CI compute time plus a small ongoing maintenance commitment, and the payoff is fewer release-day surprises on the paths that matter most.

For engineering leadership: Dusk is opt-in (composer require laravel/dusk --dev), requires no JDK or Selenium, and ships a standalone ChromeDriver. It integrates natively with PHPUnit 12 and Pest 3, exposes Page Objects and reusable components so specs stay readable, supports dusk attribute selectors that decouple tests from CSS and copy changes, and captures screenshots, console logs, and page source on failure. It tracks Laravel and PHP releases promptly (Laravel 13, PHP 8.5), so it won't block framework upgrades — but do schedule the dev-dependency bump as an explicit step in any major upgrade.

For the delivery/QA conversation: this is a complement to existing feature and HTTP tests, not a replacement. Propose a bounded first phase: one CI job, headless Chromium, a named owner, a written list of 5–10 critical journeys, and a flake policy agreed up front. Measure success by "critical journeys covered and green on the release candidate," not by line coverage. Re-evaluate at the next front-end replatform decision, and set an explicit trigger — heavy SPA migration, cross-browser requirement, or suite runtime exceeding the agreed budget — at which we switch to Playwright or a commercial grid rather than extending Dusk.