- What does pbmedia/laravel-browser-kit-macro actually do?
- It adds macro support to Laravel's BrowserKit testing layer, letting you register reusable, chainable helpers and assertions directly on your BrowserKit test case. Instead of duplicating custom assertions or building a bespoke base test class, you define macros once and share them across your suite. It is a thin, dev-time shim with no container bindings, no route or config surface, and no runtime footprint.
- Does it support Laravel's old 5.3-style tests like visit(), see(), click(), and seePageIs()?
- Yes. The package is essentially a compatibility bridge that re-exposes the Laravel 5.3 BrowserKit-style API on modern Illuminate\Foundation\Testing\TestCase classes. Keep in mind that Laravel deliberately removed that testing style, so adopting this couples your suite's forward compatibility to a package whose purpose is backward compatibility. Use it as migration scaffolding rather than a long-term architectural dependency.
- Can I use it with PHPUnit 10 or 11?
- That is not documented. The 5.9.0 release only confirms PHP 8.5 support and ships no public PHPUnit support matrix. PHPUnit 10 and 11 changed lifecycle behavior and removed annotation-era assumptions that macro registration in setUp() can trip over, so verify against your pinned PHPUnit major before committing.
- Does it depend on laravel/browser-kit-testing?
- This needs to be confirmed on your stack, because laravel/browser-kit-testing is a deprecated first-party package and is the real compatibility anchor here. Check whether this package pulls it in transitively or vendors the logic itself by inspecting composer.lock right after a dev install. Confirm that any such dependency is not pinned to the abandoned original in a way that conflicts with your Laravel version.
- How do I install and register the macros?
- Install it as a dev dependency with composer require --dev pbmedia/laravel-browser-kit-macro, then register the macro, typically via a trait in setUp() or through a service provider. Integration effort is low, so the real work is verification rather than wiring. Run the affected test subset first instead of the full suite.
- Is this package maintained and safe to rely on?
- Adoption signal is essentially absent: around two stars, zero dependents, and effectively a single maintainer. Release 5.9.0 is a genuine code change, a PHP 8.5 compatibility patch merged from an external contributor, which suggests CI runs on at least one current runtime, but that is the cheapest possible form of maintenance and does not address the deprecated-API direction of travel. Treat it as sporadically maintained and accepting community patches, not field-validated.
- Should I install the package or copy the macro trait into tests/Support?
- Vendoring the trait into tests/Support/ with a header comment pointing at the origin, including the reviewed 5.9.0 SHA, preserves the migration unblock while removing supply-chain, abandonment, and SBOM exposure entirely. The engineering cost is roughly the same as integrating the package. The idea is worth using; the dependency probably is not.
- What are the alternatives for click-through and form-flow testing in Laravel?
- Native Laravel HTTP tests handle most request and response assertions and should be the default. If your suite genuinely needs multi-page or JavaScript behavior, Dusk or Playwright are better targets than a BrowserKit shim. BrowserKit-style helpers mainly help legacy suites that are mid-upgrade.
- Will it affect production or add runtime overhead?
- No. It is a dev-time testing shim with no runtime blast radius, so keep it in require-dev and it will not ship with your application. It also stays outside your application's service container and routing, so there is nothing to configure in production.
- How hard is it to remove later?
- Exit cost is low: the macro can be deleted in a single pull request once tests are rewritten to native HTTP tests, Dusk, or Playwright. That low exit cost is exactly why vendoring the trait is attractive, since it makes removal trivial and avoids a lasting dependency on a single-maintainer package.