Weave Code
Pest Plugin Route Testing Laravel Package
spatie/pest-plugin-route-testing
Easily test every GET route in your Laravel app with Pest. Assert all routes return successful responses, include or exclude patterns, and bind models for routes with route model bindings.
spatie/pest-plugin-route-testing makes it effortless to verify that every GET route in your Laravel application responds correctly. Instead of manually writing tests for each page, call routeTesting() and chain any Laravel TestResponse assertion—such as assertSuccessful(), assertRedirect(), or assertNotFound()—to validate them all at once.
Routes with route model bindings are skipped automatically, but you can supply models via bind() to test them too, and use include() to target specific route patterns like blog*.
- Test all GET routes with a single assertion
- Use any
TestResponseassertion - include() filters routes by pattern
- bind() handles route model bindings
- Clear, readable test output
Frequently asked questions about Pest Plugin Route Testing
- What does spatie/pest-plugin-route-testing actually do?
- It adds a routeTesting() helper to your Pest suite that collects every GET route in your Laravel app, runs each one through Laravel's HTTP testing layer, and applies a TestResponse assertion such as assertSuccessful(). Instead of hand-writing a smoke test for every page, you get a single call that reports pass, fail, or skip per route. It is a thin, dev-only layer over php artisan route:list and TestResponse, with no service, config file, database schema, or production runtime footprint.
- How do I install and use spatie/pest-plugin-route-testing in Laravel?
- Install it as a dev dependency with composer require spatie/pest-plugin-route-testing --dev, then write a two-line Pest test: import the Spatie\RouteTesting\routeTesting function, call routeTesting('all GET routes'), and chain assertSuccessful(). You can narrow scope with include('blog*') or exclude('admin*'), supply models with bind(), and run setup code via setUp(). There is nothing to register or publish, so the minimal test works in minutes.
- Does this package work with PHPUnit, or do I need Pest?
- It is a Pest plugin only, so a Pest test suite is a hard prerequisite; no PHPUnit variant is shipped. Teams running PHPUnit would have to migrate their test runner or hand-roll the equivalent loop over route:list themselves. Treat that as a project decision and budget the migration before adopting the package.
- Which Pest, PHP, and Laravel versions does it support?
- Version coupling is tight and moves fast. Release 1.2.0 requires Pest 5, PHP 8.4, and Testbench ^11 (Laravel 13), while older release lines cover earlier Pest and PHP combinations. Because the package tracks upstream aggressively, verify the compatibility matrix before pinning; apps on PHP 8.2 or 8.3 may need the previous major line rather than the latest.
- Why are some routes being skipped in my route test?
- Routes with unresolved route model bindings are skipped by default instead of failing, which is why nothing breaks when a {user} parameter has no model attached. A green run can therefore mean most routes are fine rather than all of them, and that silent skipping is the biggest reporting risk. Provide models via bind('user', User::factory()->create()) and track your skip count as a metric instead of treating it as noise.
- How do I test only specific routes, like blog or admin pages?
- Chain include('blog*') to limit a run to matching routes, and exclude() to drop patterns you do not want exercised. Typical exclusions are debugbar, Telescope, Horizon, health checks, signed URLs, and webhooks that return 4xx by design. You can call routeTesting() several times with different patterns and different assertions, which keeps route groups with different expectations separate.
- Does it test POST, PUT, or DELETE routes too?
- No, the scope is GET routes only. Write endpoints and any route that mutates state are entirely out of scope. A claim of full route coverage built on this package alone is wrong and should be corrected before it reaches a status deck; pair it with behavioural tests for state-changing endpoints.
- How do I log a user in before the routes are tested?
- Use setUp() to run code before the routes are exercised, for example setUp(fn () => $this->actingAs($user)), so protected pages return 200 instead of redirecting to a login screen. Combine it with bind() for models in the URL and exclude() for routes guarded by a different policy. Without setup, authenticated routes will show up as redirects and can make an otherwise healthy app look broken.
- Is it safe to depend on a package with only 140 GitHub stars?
- The adoption signal is thin — around 140 stars, zero dependents, and a maturity signal of readme plus releases only — so weigh that honestly. Against it, the whole package is a few hundred lines of glue, MIT licensed, from a well-known Laravel house, and it sits on the seam Laravel already provides. Forkability is the real insurance here rather than the star count, so keep the version pinned and be ready to maintain a fork.
- Should I run this in CI, and will it be flaky?
- It works well as a required CI check, but route handlers can reach external services, mailers, or search clusters unless you fake or exclude them, and that is the most likely source of flakiness and environment breakage. Set a runtime budget for your route count and decide whether the goal is no 500s on public pages or enforced authorization policies, since those need different assertion sets. Also remember that skip counts on a green build are a tracked metric, not a pass.
Weaver
How can I help you explore Laravel packages today?