Pest Plugin Route Testing Laravel Package

Product Decisions This Supports

• Definition of Done for "the page exists." The package converts "we shipped a page" into an automated, repeatable check: every GET route either returns the expected status or fails the suite. This lets you standardize a completion criterion across teams without asking engineers to hand-write per-page tests.
• Release gating and regression protection. A single routeTesting()->assertSuccessful() in CI catches the class of breakage that slips through unit tests — deleted views, renamed controllers, misordered middleware, broken route caching, orphaned redirects. This is a release-blocking gate you can adopt cheaply, not a coverage program.
• Build vs. buy: buy (it's free). The alternative is a hand-rolled data provider over route:list — roughly 50–100 lines. That is a real option, but it becomes your code to maintain across Laravel and Pest upgrades. Adopting an MIT-licensed Spatie package with a narrow surface is the lower-ownership choice; a fork is a credible fallback if the package stalls.
• Roadmap sequencing for legacy/inherited apps. On an application with an unknown or undocumented page inventory, running this against production-like routes produces a concrete list of every reachable GET endpoint and its status. That output is a useful discovery artifact — it tells you which parts of the product actually exist before you plan work on them.
• QA capacity allocation. It removes the tedious "click every page" smoke pass from manual QA and from the pre-release checklist, freeing that time for flows that need human judgment. It also makes the smoke pass run on every commit instead of once per release.
• Redirect and deprecation migrations. The assertRedirect('new-section/*') pattern is a direct fit for URL restructuring, SEO migrations, and legacy-path retirement — it turns "did we map all the old URLs?" into a testable claim rather than a spreadsheet.
• Deciding how much to invest in the test estate. Because the package's output is honest about what it skipped (unresolved model bindings), it gives you a defensible number for "how much of the app is actually smoke-covered" — which is the input to a real testing-investment conversation, rather than a vanity percentage.

When to Consider This Package

Adopt when most of these hold:

• The application is Laravel and already uses Pest. This is non-negotiable — it is a Pest plugin, not a PHPUnit plugin. If the team is on PHPUnit, the adoption cost is a framework migration, not a composer require.
• You have, or expect to have, a meaningful number of GET routes (roughly: more than a handful of pages, or any app with a public-facing surface). Below that, a couple of hand-written tests are simpler.
• The routes are reachable without complex per-route setup — or you can express that setup once via setUp() (e.g., actingAs() plus a couple of bind() calls).
• You want a cheap, high-signal CI gate and are willing to treat skips as a known, tracked gap rather than pretending coverage is complete.
• Your framework/PHP line matches a supported branch: 1.2.x → Pest 5, PHP 8.4, Testbench ^11 (Laravel 13); 1.1.x → Pest 3 era (Laravel 11/12, PHP 8.2/8.3). Confirm this before committing — the package version is a function of your stack, not an independent choice. Assume the 1.1.x branch gets little further work.

Look elsewhere — or defer — when:

• You are not on Pest. Hand-roll the route:list data provider instead; it is materially the same thing and avoids a test-framework migration you did not want.
• Your surface is mostly API or POST/PUT/DELETE. The package tests GET routes only. It will not cover your primary contract, and adopting it may create a false impression that the API is covered.
• Most routes need per-route fixtures to be meaningful. With default-skipped model bindings, an app built on user/{user}-style paths yields a large skip list out of the box. If resolving that list is a big project, the package's headline value shrinks accordingly.
• You need functional assertions (does this form do the right thing, does this page show the right data to the right role). This is a smoke-test generator, not a functional test framework; it should sit alongside, not replace, real tests.
• You require a support contract or vendor accountability. 141 stars, zero dependents, MIT, single-maintainer-adjacent governance. Forkability is the mitigation, not a support agreement.

How to Pitch It (Stakeholders)

For executives — one paragraph: This is a small, free, dev-only testing utility for our Laravel application. It turns "did we break any page?" from a manual pre-release click-through into an automated check that runs on every code change, and it costs us roughly a day of engineering to adopt with no production footprint and no ongoing license. The honest framing is that it raises the floor, not the ceiling: it proves pages respond correctly, not that they work correctly. We should present it as reducing a specific, recurring class of release risk — broken routes reaching customers — and as freeing QA time for higher-value testing, not as a coverage milestone.

For engineering — the ask: Add a dev-only dependency and one test file. It resolves the route table via Laravel's public route:list API into Pest data providers, issues each GET through the standard HTTP test harness, and delegates assertions to TestResponse — so include()/exclude() wildcards, bind(), setUp(), and snapshot assertions all behave exactly as the team already expects. Reversal is one composer remove commit. Two caveats to state plainly rather than bury: (1) it requires Pest, and the version we can use is dictated by our Pest/PHP/Laravel line — settle that first; (2) GET-only plus bindings-skipped-by-default means "all routes pass" is true-by-construction only over the subset we resolved, so the skip list is the actual roadmap for follow-up work.

The one risk to name up front: coverage illusion. A green badge that reads "all routes pass" while a meaningful set was silently skipped is worse than no badge, because stakeholders will treat it as assurance. Mitigate with a product decision, not a technical one: publish the skip count, assign an owner to burn it down, and never report route-test results without the skipped number attached.