Browser Laravel Package

Product Decisions This Supports

• Test-strategy investment (test pyramid economics). The package's core value proposition is a two-tier browser abstraction: KernelBrowser runs in-process against the Symfony kernel (fast, no webserver) while PantherBrowser drives a real browser via symfony/panther (slow, JS-capable). That directly supports a decision to keep the bulk of acceptance tests fast and reserve real-browser coverage only for JS-dependent flows — a measurable lever on CI cost and feedback time.
• Build vs. buy for internal test tooling. Teams frequently hand-roll fluent test wrappers, custom assertion helpers, and failure-artifact capture. This package bundles all three (fluent assertions, form/field helpers, auth helpers, profiler access, and a PHPUnit extension that saves page source/screenshots/JS console logs on failure plus a console summary). Buying (adopting) is clearly cheaper than building if you're on Symfony + PHPUnit.
• Coverage expansion into under-tested areas. Concrete, already-solved use cases: authenticated user journeys (actingAs, assertAuthenticated — and, as of v1.13.0, injecting an HTTP session directly into use() so a pre-authenticated session can be reused across scenarios), form submission and validation UX (fillField, selectField, assertFieldEquals, assertChecked), redirect chains (assertRedirectedTo, clickAndIntercept), API/JSON contracts (assertJsonMatches with JMESPath), and exception-path testing (expectException + request). Each of these is a roadmap item ("we should test X") that this package makes cheap enough to actually schedule.
• Flake and triage reduction as a product-quality KPI. Automatic artifact capture on failure is a support-cost feature, not a nicety: it shortens the debug loop for engineers and reduces "cannot reproduce in CI" tickets. v1.13.0 hardened exactly this surface — unique artifact filenames to remove a race under paratest, browser actions after an expected exception now fail loudly instead of silently passing, and request-option merging no longer mutates shared defaults. Those are false-green and flake classes being closed, which makes "mean time to diagnose a red build" a defensible OKR rather than an aspiration.
• Trust in the suite (signal quality). A test tool that can silently no-op after an expected exception produces green builds that lie. The v1.13.0 fix is a small but material improvement to whether a passing suite means what stakeholders assume it means.
• Fixture/data-seeding alignment. Explicit pairing with zenstruck/foundry means test data setup and browser assertions share one idiom — relevant if you're standardizing test conventions across squads.
• Feature-scope decisions on "how much browser do we need?" Because the same fluent API spans kernel-level and Panther-level, the decision "does this feature need a real browser?" becomes a per-test toggle rather than an architecture choice — useful when scoping QA effort per epic.

Important caveat for a Laravel context: this is a Symfony package (KernelBrowser wraps Symfony\Bundle\FrameworkBundle\Test\WebTestCase; PantherBrowser wraps Symfony\Component\Panther\PantherTestCase). It is not usable in a Laravel application as-is. Any adoption decision here is a Symfony-ecosystem decision; for Laravel the equivalents are Laravel's native HTTP test helpers ($this->get(), assertSee, assertJson*), Laravel Dusk for browser tests, and Pest expectations. Nothing in v1.13.0 changes that boundary.

When to Consider This Package

Adopt when:

• The application is Symfony 5.4/6.x/7.x on PHPUnit (8, 9, or 10+ — extension registration differs; both are documented).
• You already have, or plan to have, a functional-test layer extending KernelTestCase/WebTestCase, and the pain is verbosity and readability, not missing capability.
• You want failure artifacts for free (page source, screenshots, JS console logs) without wiring your own CI plumbing — and you run tests in parallel, where v1.13.0 fixes an artifact-filename race under paratest.
• You need light JS coverage and want to avoid standing up Cypress/Playwright for a handful of flows.
• You're willing to take it as a --dev dependency (zero production/runtime footprint; MIT license; no procurement friction).
• You're already in the zenstruck ecosystem (Foundry) and value a consistent authoring style.

Look elsewhere when:

• The stack is Laravel or any non-Symfony framework. Hard stop — the abstractions are Symfony-kernel-bound. Use Laravel's HTTP test helpers + Dusk, or Pest.
• You need serious E2E: cross-browser matrices, mobile viewports, network interception, visual regression, multi-tab/multi-context, video traces. PantherBrowser is a convenience layer, not a Playwright/Cypress replacement.
• Governance risk outweighs benefit. Signals to weigh honestly: ~229 GitHub stars, 0 recorded dependents, a single-maintainer-style project, and no commercial support/vendor SLA. For a large org with long-lived test infrastructure, that's a bus-factor conversation — mitigate with a pinned version, an internal fork option, or by keeping the abstraction thin enough to swap. Counter-signal from v1.13.0: an external contributor is landing features and fixes alongside the maintainer, and the release is bug-fix-weighted rather than feature-sprawl — modest evidence of a maintained, conservative project.
• The team is Pest-first or wants a single test idiom — mixing PHPUnit-extension-based tooling with Pest adds cognitive overhead.
• You want the tool to own test data; it doesn't. It assumes a fixture layer (Foundry or your own).

Release-level read on v1.13.0 (upgrade risk): low. One additive feature (HTTP session injection into use()), three correctness/robustness fixes, and a CI pin (Playwright 1.62.1 for reproducible browser runs). No breaking changes, no deprecations — safe as a routine minor bump within the 1.x line; no test rewrite implied. Plan it as a normal dependency refresh, not a migration.

Data to verify before committing (don't decide on the score alone):

• "Last release: 2026-10-10" is an anomalous/future-dated signal — v1.13.0 confirms releases are in fact shipping; still confirm cadence and recent commit activity directly on the repo rather than trusting a single date field.
• "Dependents: 0" likely reflects missing Packagist metadata rather than true zero usage; check Packagist download stats and GitHub usage instead of trusting this field.
• The composite score (~38.6, opportunity ~54.2) is not a recommendation — it's a screen. Budget a timeboxed spike (1–2 days): port 3–5 existing slow/flaky tests to KernelBrowser and one JS flow to PantherBrowser, then measure.

Spike success criteria (decide with these, not vibes): suite runtime delta, lines-of-test-code reduction, time-to-first-green for a new engineer, and whether the failure-artifact extension actually shortens triage.

How to Pitch It (Stakeholders)

One-liner for executives: A free, MIT-licensed developer tool that makes our Symfony functional tests shorter, faster, and easier to debug — it's a dev-only dependency with no production footprint, and it's designed to be adopted one test at a time rather than as a rewrite.

Why it matters commercially:

• Cost: $0 licensing, no vendor contract, no infrastructure. Removes the main reason teams skip functional-test coverage (writing them is tedious).
• Speed to market: faster, more readable tests → engineers write and maintain more of them → regressions caught before release instead of in support.
• Risk, stated plainly: small open-source project, low public adoption signals, single-maintainer risk. We contain that by pinning versions and keeping usage at the test layer where it can be replaced. It is not in the production dependency graph. The latest release is a routine, non-breaking patch-quality bump — ongoing maintenance without churn.
• Scope clarity: This is a Symfony tool. If any part of the roadmap is Laravel, this does not apply there — Laravel ships equivalent capabilities natively, and Dusk covers the browser case.

For engineering:

• Fluent, auto-completable API chained off $this->browser(); works inside existing WebTestCase/PantherTestCase classes via the HasBrowser trait — no test-framework migration.
• One API across KernelBrowser (in-process, fast) and PantherBrowser (real browser, for JS), so you pick speed vs. fidelity per test.
• Ships assertions we currently hand-write: status/headers, visibility, element counts/attributes, form field state, auth state, redirect chains, and JMESPath JSON assertions for API endpoints.
• Enables the PHPUnit extension → on failure we get source, screenshots, and JS console logs automatically, plus a summary at the end of the run. That's the ticket-deflection feature; artifact naming is now race-safe under parallel test runners.
• Upgrade to v1.13.0 is low-risk and worth taking if we adopt: it fixes a class of false-green builds (acting on the browser after an expected exception now fails as it should), stops request options from mutating shared defaults, and lets us inject an authenticated session via use() instead of re-logging in per test. Pin Playwright to the version the project CI pins to keep browser runs reproducible.
• Pairs with zenstruck/foundry for expressive fixtures; also exposes the Symfony profiler for query-count and request assertions when you need performance guardrails in tests.

Recommendation: Approve a timeboxed evaluation spike (3–5 tests, one JS flow), with adoption gated on measured runtime and maintainability improvement. Adopt on the current 1.x release (≥ v1.13.0); pin the version. Reject outright replacement of existing E2E tooling; position this as the fast tier of a two-tier test strategy, not a Playwright/Cypress substitute.