Weave Code
Laravel Dusk Fakes Laravel Package
protonemedia/laravel-dusk-fakes
Laravel Dusk Fakes lets you replace real Dusk browser sessions with fakes in your tests. It offers a fluent API to simulate browser interactions and assert Dusk calls, so you can test Dusk-dependent code quickly without launching a real browser.
Persistent Fakes for Laravel Dusk
Frequently asked questions about Laravel Dusk Fakes
- What is protonemedia/laravel-dusk-fakes and what problem does it solve?
- It is a Laravel package that provides persistent versions of Laravel's native fakes for use with Laravel Dusk. Dusk drives your application through a real browser in a separate PHP process, so fakes registered in the test process never see what the app process actually did. This package records fake interactions to a shared store that both processes can read, so a Dusk test can assert that mail, notifications, jobs or events were dispatched. Architecturally it is a thin, opt-in shim over the framework's fake infrastructure rather than a new testing paradigm.
- How do I install laravel-dusk-fakes in a Laravel app?
- Install it with Composer as a dev dependency: composer require protonemedia/laravel-dusk-fakes --dev. Package auto-discovery registers the service provider, and you publish the config file to choose the persistence backend. No production code changes or schema changes are needed beyond whatever store you select. A developer already familiar with Dusk can usually have a working spike in well under a day.
- Which fakes does laravel-dusk-fakes cover?
- The package is built around Laravel's native fakes, with Mail, Notification, Queue, Event and Bus being the ones it targets, persisting their recorded interactions so the Dusk process can assert on them. Because it tracks framework internals, exact coverage and assertion parity can vary between releases, so confirm the current list against the README for the version you install. Everything is opt-in, so any fake you do not swap behaves exactly as it normally does.
- What persistence backend does it use and can I configure it?
- Persistence is configurable through a published config file, with the shared store backed by Laravel's cache, filesystem or database layer depending on your setup. Pick the backend based on what is reliably shared between the test process and the browser-driven application process in your environment. In containerized CI, a shared file or database store usually behaves more predictably than an in-memory cache.
- Does laravel-dusk-fakes clean up between tests and what happens if a test crashes?
- A persisted fake store introduces a statefulness risk that native fakes do not have, so flush it explicitly in setUp or tearDown for every test. If a test crashes mid-run, recorded interactions can leak into the next test, which is why explicit cleanup is safer than relying only on teardown hygiene. Treat store isolation as part of your test contract rather than an implementation detail.
- Can I use laravel-dusk-fakes with Laravel parallel testing?
- Yes, but you must isolate the store per process, otherwise parallel workers read and write the same recorded interactions. Scope the store by a worker or process token, for example a file path or cache key that includes the parallel test token, or run these specific tests serially. Verify isolation early, because contamination failures look like flaky tests rather than configuration mistakes.
- Does laravel-dusk-fakes support Laravel 13 and newer versions?
- Release 1.10.0 added Laravel 13 support, building on support for earlier major versions. The package touches framework internals such as fake classes and container bindings, which have historically shifted across Laravel majors, so being supported in composer.json and being verified in your configuration are different things. Run a small spike against your exact Laravel and Dusk versions before relying on it in a large suite.
- Do I need to change my application code to use laravel-dusk-fakes?
- No. It is a test-only, opt-in package, so you swap in the persistent fake per test and everything outside the test environment stays untouched. Keep native fakes for feature and integration tests where they already work, and scope this package to the Dusk tests that need cross-process assertions. That additive approach keeps the blast radius small and the migration reversible.
- How does laravel-dusk-fakes compare to Pest browser testing, Cypress or Playwright?
- If you are using Pest browser testing, Cypress or Playwright, you can often assert at a boundary you control instead of adding a persistent fake layer. This package is aimed at teams with an existing Dusk suite that already tests flows involving mail, notifications, jobs or events and has hit the wall of not being able to assert on side effects from a browser test. It complements native fakes rather than replacing them, and it is a poor fit if you assert via Http::fake() at the boundary.
- Is protonemedia/laravel-dusk-fakes actively maintained and safe to depend on?
- It is maintained by Protone Media (Pascal Baljet), a credible Laravel package author, and the 1.10.0 release is evidence of ongoing stewardship. That said, the package has roughly 21 GitHub stars and effectively zero dependents, so there is little downstream validation and single-maintainer risk remains. Weigh that against its coupling to framework internals, and pin a version you have actually tested in your own CI.
Weaver
How can I help you explore Laravel packages today?