Weave Code
Browser Kit Laravel Package
symfony/browser-kit
Symfony BrowserKit simulates a web browser in PHP, letting you make requests, click links, and submit forms programmatically. Includes an HttpClient-based implementation for real HTTP requests, ideal for functional tests and scraping.
Symfony BrowserKit simulates a web browser in PHP, letting you programmatically make requests, click links, and submit forms as if a real user were navigating your application. It provides an abstract client with a concrete implementation built on the HttpClient component for real HTTP requests.
Ideal for functional testing and web scraping, BrowserKit integrates seamlessly with Symfony's test tooling.
- Programmatic link clicking and form submission
- Cookie and session handling across requests
- History and back/forward navigation support
- Works with real HTTP or custom client backends
- Extensible via the
AbstractBrowserbase class
Frequently asked questions about Browser Kit
- Does symfony/browser-kit work with Laravel out of the box?
- No. BrowserKit is a browser simulation abstraction, not a Laravel test runner, and the class that turns a simulated request into a kernel dispatch, KernelBrowser, ships in symfony/framework-bundle rather than in this package. To use it against a Laravel app you must write your own client extending AbstractBrowser that maps a BrowserKit Request onto Illuminate\Http\Request and calls Illuminate\Contracts\Http\Kernel::handle(). Budget roughly 200 to 400 lines of glue plus its own test suite rather than treating it as a single composer require.
- How do I install symfony/browser-kit in a Laravel app?
- Install it as a dev dependency with Composer, for example composer require --dev symfony/browser-kit symfony/css-selector. symfony/dom-crawler is a hard requirement and is pulled in automatically, but symfony/css-selector is a separate package needed for CSS-style selectors, and neither is a Laravel default. There are no browser binaries, no Node, no Selenium grid and no daemon to run, so installation is purely a Composer step.
- What is the difference between BrowserKit and Laravel's built-in HTTP testing helpers?
- Laravel's own get, post and actingAs helpers are already kernel-aware and are simpler for single-request assertions on status codes, JSON payloads and redirects. BrowserKit adds a higher-level simulation layer: clicking links and buttons by selector or text, submitting forms including hidden inputs, following redirects with limits, a spec-shaped cookie jar with domain, path and expiry handling, and history navigation with back, forward, restart, isFirstPage and isLastPage. Reach for BrowserKit when you want to script multi-step user journeys against rendered markup rather than issue individual requests.
- What do I actually have to build to connect BrowserKit to a Laravel application?
- You need one concrete class extending AbstractBrowser that converts BrowserKit's Request value object into an Illuminate\Http\Request, boots the application, dispatches through the HTTP kernel, and wraps the resulting response back into a BrowserKit Response, including headers, cookies and content. The harder decision is lifecycle: booting the kernel once and reusing it is fast but leaks container, session and static state between requests, while booting per request is correct but slower, and there is no upstream guidance for this on the Laravel side. Treat the glue as a version-locked artifact you own and test, not as boilerplate.
- Which PHP and Symfony versions does BrowserKit support, and how should I pin it?
- Symfony majors land roughly every two years, and the 8.x line requires PHP 8.4 or newer, so check your runtime before adopting it. Pin to a floor rather than floating a range: the 8.1.x line shipped behavioural cookie fixes, with 8.1.9 correcting cookie parsing and path matching across the 8.1.6 to 8.1.8 range, and the cookie jar is the component most load-bearing for login and session journeys. Also note that Symfony 8 enforced return types across all components, so an AbstractBrowser subclass written against 7.x can fail to compile on 8.x without compatible signatures.
- Does symfony/browser-kit execute JavaScript?
- No, by design. It parses and navigates server-rendered HTML but never runs scripts, so anything that depends on client-side rendering, WebSockets or async XHR will not be exercised, and assertions around those journeys can silently pass when they should not. That is the same wall that pushes teams toward Laravel Dusk or Panther, and it is a constraint to design around rather than a bug to patch.
- Can BrowserKit handle CSRF tokens, logins and session cookies in Laravel tests?
- Yes, provided your glue is correct. Form submission includes hidden inputs, so a CSRF token that is present in the rendered form is submitted automatically, and the cookie jar tracks domain, path and expiry so sessions survive across requests. The common failure mode is reusing a stale container or session between requests, which presents as apparently dropped cookies or rejected tokens; the 8.1.9 fix to cookie path matching on sub-path requests is a reminder that this layer is behavioural and worth pinning deliberately.
- How do I use BrowserKit with PHPUnit or Pest, and what can I assert?
- It composes cleanly with both PHPUnit and Pest, and the whole integration can live under tests/ or in a dedicated tooling package. You assert against the response object for status, headers and cookies, against the crawler for DOM and selector queries, and against the client for history state using helpers such as isFirstPage and isLastPage. Symfony 8 and 7.4 added matching PHPUnit constraints for those history checks, so you do not have to hand-roll them.
- Is it safe to add symfony/browser-kit to a production Laravel project?
- It is a test-infrastructure decision with effectively no production blast radius: install it with --dev, keep the glue under tests/, and you can reverse the whole thing in an afternoon because no application code changes are required. The package is MIT licensed and Composer-installable, with no browser binaries or external services involved. The only real ongoing cost is maintaining and upgrading the kernel glue you write yourself.
- What are the alternatives to BrowserKit, and is the package well maintained?
- Laravel's built-in HTTP test helpers cover simple request assertions, while Dusk and Panther cover journeys that need a real browser and JavaScript. BrowserKit sits in between and underpins Symfony's own WebTestCase, Panther and Codeception's Symfony module, so a dependents count of zero is a monorepo artifact of releases being split from symfony/symfony rather than evidence of abandonment. The caveat is that there is no public registry of Laravel integrations, so on the Laravel side you are an early adopter writing and owning the glue yourself.
Weaver
How can I help you explore Laravel packages today?