Pest 5 shipped on stage at Laracon US in Boston on July 28, presented by Nuno Maduro as the biggest Pest release yet. We were in the room, and three weeks later we upgraded the Laravel application behind our website, redberry.international, from Pest 4 to Pest 5 - and measured everything on the way: raw suite times before and after, the new Test Impact Analysis engine under five realistic scenarios, and exactly what the migration cost us in code changes.

One thing to know up front: Redberry sponsors Pest and has for over a year, and we sponsored Laracon US 2026 where it launched. That is precisely why every number below comes from our own controlled benchmark rather than the announcement post - praise is cheap, measurements are not.

The short version: the upgrade cost us three lines and zero code changes, raw test speed stayed exactly where it was, and the TIA engine turned a 102-second suite into a tool we now run after every save. That last part is the whole story.

How big is the Pest 4 to Pest 5 upgrade?

For our production suite of 139 tests and 497 assertions, the entire Pest 4 to Pest 5 upgrade was three lines in composer.json and zero changes to test code.

-    "pestphp/pest": "^4.0",
-    "pestphp/pest-plugin-laravel": "^4.0",
-    "phpunit/phpunit": "^12.5",
+    "pestphp/pest": "^5.0",
+    "pestphp/pest-plugin-laravel": "^5.0",
+    "phpunit/phpunit": "^13.0",

One composer update -W later we were on Pest 5.1.1 and PHPUnit 13.3.0. Our phpunit.xml passed validation untouched. We audited the test suite against every removal and deprecation in PHPUnit 13.0 through 13.3 before upgrading: zero occurrences of any of them. The dependency footprint grew by one locked package and about a megabyte of vendor/ - for a new major version of a framework, essentially free.

Two prerequisites gate that simplicity, and only one of them is documented. The first: Pest 5 requires PHP 8.4.0 or greater, up from 8.3.0 in Pest 4. We were already on 8.4, which is why our diff is three lines - if you are still on 8.3, the PHP upgrade is the actual project and the Pest bump is the trailer hitched to it. The second prerequisite is not in the upgrade guide at all, and it is the next section.

Pest majors have not always been this quiet: 3 to 4 required regenerating snapshot names and archived two plugins, pest-plugin-watch and pest-plugin-faker - our engineers wrote up how Pest 4 felt in practice when it landed. 4 to 5 asked nothing of our code. Fair warning if you lean on snapshots, architecture tests, or browser tests: audit those corners first, because our suite happens to use none of them, and that is part of why our migration was free.

Do you need Laravel 13 for Pest 5?

Yes - plan the Laravel 13 upgrade first, because Pest 5 installs on Laravel 13 and not on Laravel 12 or 11.

The reason is a shared dependency: Pest 5 and older Laravel releases require versions of symfony/process that cannot coexist, and Composer can only install one. This is not mentioned in the upgrade guide's requirements, so it is worth knowing before you schedule the work: what looks like a two-minute version bump is really "finish your Laravel 13 upgrade, then enjoy a two-minute version bump." We did exactly that - framework first, then Pest - and the second step went as smoothly as the estimate promises.

If you are already on Laravel 13, note that its upgrade guide still suggests Pest 4. Pest 5 runs on Laravel 13 without issue; the guidance simply predates the release.

Is Pest 5 faster than Pest 4?

In raw execution speed, no - and we consider that the most noteworthy thing we can tell you.

We benchmarked both versions on the same codebase with Laravel 13.26.1 held constant, three runs per configuration, reporting the median. Serial: 103.90 seconds on Pest 4, 102.24 on Pest 5. Parallel across eight processes: 65.99 versus 67.11. Both deltas sit far inside the run-to-run variance we observed (up to 17 percent), so the honest reading is: identical. Same tests dominate the profile in both versions, same distribution, same shape.

That sounds like an anticlimax until you see what Pest 5 is actually doing. The performance story of this release is not about running your tests faster. It is about not running most of them at all.

What does the TIA engine change?

On our suite, Pest 5's Test Impact Analysis replays an unchanged 139-test run in 0.46 seconds instead of 102, and real day-to-day edits run 2x to 3.3x faster.

TIA is new in Pest 5. On its first run with --tia, Pest records which tests depend on which files - a one-time cost of about 40 extra seconds on our suite, paid back in full on the very next run. That recording pass needs a coverage driver, so PCOV or Xdebug has to be installed: the one setup prerequisite worth checking before you promise the team a faster loop. From then on, Pest re-runs only the tests your change can actually affect and replays cached results for everything else, coverage intact.

What we measured, against our 102-second baseline:

The comment-only row is our favorite. TIA understood that a docblock edit cannot change behavior and re-ran nothing - this is real impact analysis, not file-timestamp caching. And the honest expectation to set is the 2x to 3.3x band, not the 222x of the nothing-changed case: the blast radius scales with how widely depended-upon the file you touched is.

Here is why this matters more than a raw speedup ever could. Test-driven development lives or dies on the cost of the feedback loop. At 102 seconds, you run the suite before a commit. At a few seconds for a typical edit, you run it after every save - and that is the habit TDD actually depends on. Pest 5 does not make testing faster so much as it makes testing constant, and we have already felt the difference in daily work. Two ground rules from our setup: TIA is a local-development tool, so CI still runs the full suite every time, and the dependency graph lives in the system temp directory, so there is nothing new to commit.

What else ships in Pest 5?

TIA headlines, but the release is broad, and three more pieces stood out in practice.

Time-balanced sharding. pest --update-shards records real per-class timings into a committable file, and --shard=1/4 then splits CI by measured time instead of test count. Our own CI currently splits by suite name, which is about as unbalanced as splitting gets - this replaces guesswork with data, and we are adopting it.

The Agent plugin. AI coding agents can verify their changes inside your real test environment - factories, database, Laravel fakes, even a real browser - instead of only checking that the UI looks right. An agent can now prove the job was queued and the row was written. For a team like ours shipping AI-assisted work daily, verification this grounded is the right direction.

Native Evals. Pest 5 ships a first-party plugin for scoring LLM output, mixing deterministic checks with AI-judged scorers in the familiar expect() API. This one is personal: we built our own open-source pest-plugin-evals on Pest 4, because client work with AI features needs tests that show evidence, not vibes. We saw the need for evals in the ecosystem, and we are glad Nuno and the Pest core team saw it too and made it native - validation of the problem, solved at the level where the whole community benefits.

Rounding it out: a first-party PHPStan plugin that finally teaches static analysis about it() and expect(), a Rector plugin with around 60 rules for modernizing suites, and a set of new format expectations like toBeEmail() and toBeUlid().

So, is Pest 5 worth it?

Yes - not because it runs your existing tests faster, but because it changes what a test suite costs to live with.

The upgrade itself is as small as a major version gets: three lines, zero code changes, and two honest prerequisites in PHP 8.4 and Laravel 13. What you get back is a test loop measured in seconds instead of minutes, CI shards balanced by real timings, and first-class answers to questions - agent verification, LLM evals - that most testing frameworks have not started asking. Days after upgrading, the thing we remember is simple: the suite stopped being something we wait for.

If Pest 5 is this good at making tests cheap to run, the excuses for not writing them are getting thin. That might be its real contribution.