You change one validation rule in a FormRequest. CI dutifully grinds through four thousand tests for eleven minutes, roughly three of which had any business running. We've all accepted this as the price of confidence. Pest 5 is the first major release in our corner of the ecosystem that treats that price as negotiable — and, more interestingly, the first that openly assumes some of the diffs landing in your repo were never typed by a person.
Here's my position up front: that assumption is correct, and building a test framework around it is the right move, even if parts of it will age badly. A suite that only speaks to humans is already behind how code gets written in 2026. Pest 5's most debated features — the Agent plugin and Evals — aren't hype decoration. They're an admission that the second user of your test suite is a machine, and that machine needs to be told when it's wrong just as bluntly as a junior dev on their first pull request.
First, the sober inventory, because the changelog is easy to misread. The minimum PHP version jumps to 8.4. Underneath, you're now on PHPUnit 13. Test Impact Analysis selects the subset of tests related to your diff instead of firing everything. PHPStan and Rector get pointed at your test code, which historically has been the least-analyzed code in any Laravel repo I've touched. What's not a Pest 5 story: browser testing shipped with Pest 4, and time-balanced sharding landed back in 4.6. If your upgrade pitch to the team leans on those two, someone will rightly call it out in review.
Test Impact Analysis deserves both the applause and a warning label. Locally, it turns the run-tests-after-every-save habit from a fantasy into something you'll actually do, and a habit you actually keep beats a ritual you skip. But think about how much of a Laravel app is wired at runtime: container bindings swapped in a service provider, listeners registered in an EventServiceProvider, behavior toggled by config or a morph map. No diff-based selection can see all of that. My rule: impacted tests on every save, full suite before merge. Treat the fast path as a scout, not as the verdict.
The Agent plugin is where opinions split at conference bars. The idea: a coding assistant shouldn't grade its own homework by rereading its diff — it should be able to check its claims against a booted application. Did that migration actually add the column? Is the job really sitting on the queue after the request? That's not AI worship; that's applying the oldest rule we have — don't trust, verify — to a new kind of contributor. Evals extend the same honesty to model output itself: when the answer legitimately varies between runs, you assert properties and boundaries instead of pretending assertSame() settles it.
Now the strongest case against me, stated fairly. One: the PHP 8.4 requirement is a real wall. Plenty of teams run 8.2 or 8.3 in production for reasons that have nothing to do with laziness — vendor images, compliance freezes, that one extension nobody dares recompile. For them, Pest 5 is a 2027 conversation, and that's fine. Two: test frameworks have a long memory, and bolting on tools for this year's workflow risks carrying dead weight in five years. Maybe Evals won't survive in their current shape. I'll take that risk anyway, because the alternative — a testing story that ignores how patches are actually produced on my team right now — costs me more this quarter than a deprecated plugin costs me later.
What I keep coming back to is that none of this changes what a test is. It changes who reads the red X. When the reader is a human, a failure is feedback. When the reader is an agent, a failure is a guardrail — the only thing standing between a confident-sounding patch and your main branch. I'd rather have a framework that takes that second role seriously than one that pretends it's still 2019.
So, colleagues, two questions I genuinely want answered in the comments: would you gate a merge on impacted-tests-only, ever — or is the full suite before main non-negotiable in your shop, no matter how good the selection gets? And have you actually let an assistant run your tests unattended yet, or does a human still press the button? Tell me where your line is, and why.
Comments
No comments yet — be the first.
Open the discussion
No account or password needed — just enter your e-mail and we’ll send you a one-time sign-in link. First time here? You’re set up automatically.
Your rating will be applied automatically after you sign in.
Check your inbox
We’ve sent a sign-in link to …. Open it on this device — this tab will sign you in automatically.
Nothing arrived? Check your spam folder — and mark the mail as "Not spam" so it lands in your inbox next time.