Programing
Pest 5 Announcement: Enforcing PHP 8.4+ as the New Testing Standard
Published:
•
Duration: 6:25
0:00
0:00
Transcript
Host: Alex Chan Hey everyone, welcome back to Allur! I’m your host, Alex Chan, and I am honestly so pumped for today’s episode. If you’ve been hanging around the PHP ecosystem for any amount of time lately, you know that the "Pest vs. PHPUnit" debate has kind of settled into this beautiful reality where Pest has just... well, it’s changed the way we think about testing. It made it elegant, right? It made it feel less like a chore and more like writing actual prose.
Host: Alex Chan To help me break this down, I’ve got a very special guest. Joining me today is Julian Vance. Julian is a veteran PHP architect, a frequent contributor to open-source testing tools, and someone who has been tracking the internals of PHP 8.4 very closely. Julian, welcome to Allur!
Guest: Julian Vance Thanks, Alex! It’s great to be here. Honestly, when that announcement hit my feed, my first thought was, "Wow, they actually did it." It’s a bold move, but man, is it a necessary one for where PHP is headed.
Host: Alex Chan Right? I mean, my initial reaction was a bit of a gasp. PHP 8.4 as a *minimum*? That feels aggressive, especially when so many companies are still, let's be honest, struggling to get off 7.4 or barely hitting 8.1. But then I saw the release date—July 2026. That gives us some runway. But Julian, from your perspective, why 8.4 specifically? Why not just stick with 8.2 or 8.3?
Guest: Julian Vance It’s a great question. And you know, I think we have to look at what's actually *in* PHP 8.4. We’re talking about things like property hooks, which are going to completely change how we handle DTOs and data mapping. We're talking about asymmetric visibility—where you can have a property that's public to read but private to set. If you're building a testing framework like Pest, which relies so heavily on a clean, "magic-but-not-too-magic" API, having those native engine features allows the Pest team to rip out a lot of the "hacky" workarounds they had to use for older versions.
Host: Alex Chan Oh, interesting! So it’s not just about us, the users, having cool new features in our tests, it’s about the actual internal health of the Pest framework itself?
Guest: Julian Vance Exactly. Um, actually, if you look at the maintenance burden of supporting PHP 8.1 through 8.4, it’s a nightmare. You’re constantly writing `if` statements in your core code. "If the version is this, do this weird reflection trick; if it’s that, use this other trick." By saying "8.4 or bust," the Pest team can essentially rewrite their core to be faster, leaner, and—most importantly—more stable. It’s about leveraging the full power of the modern engine instead of being held back by the lowest common denominator.
Host: Alex Chan That makes so much sense. I remember when Pest first came out, the big "aha" moment for me was how it felt like I was writing a story. It was so... fluid. But I’ve definitely run into those moments where the underlying PHP engine felt like it was fighting against that fluidity.
Guest: Julian Vance Right! And think about the Developer Experience—the DX. One of the goals for Pest 5 is making the testing paradigm even more intuitive. With 8.4’s new features, they can make things like expectations and mocks feel even more native. I’ve seen some early discussions about how they might use property hooks internally to handle test state, and it’s honestly brilliant. It reduces the overhead. But, I have to ask you, Alex—as someone who talks to a lot of developers—does the "July 2026" date feel too far away or just right?
Host: Alex Chan Honestly? It feels like a challenge. It’s like a ticking clock, right? Like, "Hey, you have two years to get your infrastructure in order." I think it’s a smart move because it forces the hand of DevOps teams and CTOs. If you want the best testing tools, you can't stay on an ancient stack. But... I can already hear the groans from the devs working on massive 10-year-old monoliths. Have you ever been in a spot where you wanted to use a tool like this but the "engine" just wouldn't let you?
Guest: Guest: Julian Vance Oh, absolutely. I spent a year at a firm where we were stuck on PHP 7.2 long after 8.0 was out. We wanted to use the latest Pest features back then, but we couldn't. We ended up in this "version limbo" where our tests felt clunky because we couldn't use the latest syntax. It actually hurts morale! Developers want to use the shiny stuff. When Pest 5 says "8.4 only," it gives the developers a business case to tell their managers: "Look, if we want to stay modern and keep our testing suite efficient, we *have* to prioritize this upgrade."
Host: Alex Chan That's such a good point. It’s almost like Pest is acting as the "bad cop" for the ecosystem, forcing everyone to level up. I love that. "Upgrade your engine or you don't get the cool toys." (laughs)
Guest: Julian Vance (laughs) Exactly! And it’s not just about being "cool." It’s about security and performance. PHP 8.4 is going to be significantly more optimized. If Pest 5 is built on that, your test suite—which might have thousands of tests—could potentially run 20% or 30% faster just because of the engine improvements and the leaner framework code. Think about the CI/CD costs you’re saving there.
Host: Alex Chan Wait, 20 to 30 percent? That’s massive when you’re talking about a pipeline that runs a hundred times a day.
Guest: Julian Vance It really is. And that’s the "aha" moment for the business side. "Oh, this isn't just about Julian wanting to use fancy new property hooks; this is about our build taking 5 minutes instead of 10."
Host: Alex Chan I love that. So, let’s talk about the struggle for a second. If I’m a dev listening to this, and I’m currently on PHP 8.1, and I’m looking at Pest 5 in 2026... what’s the roadmap? Does this mean Pest 4 is the "end of the road" for older versions?
Guest: Julian Vance Pretty much. Pest 4 will likely become the "LTS" or the long-term support version for those on 8.2 or 8.3. But all the innovation—the really ground-breaking stuff—is going to happen in version 5. My advice to anyone listening is: don’t wait until July 2026. PHP 8.4 is coming out much sooner than that. Start the migration path now. Get to 8.2, then 8.3. Make it a culture of constant small upgrades rather than one giant, painful jump every four years.
Host: Alex Chan "Constant small upgrades." That should be a mantra for every dev team. It’s so much less scary than the "Big Migration."
Guest: Julian Vance It really is. And Pest has always been about making things less scary. I think this announcement is their way of saying, "We’re confident in the future of PHP." They aren’t worried about PHP dying; they’re betting big on its evolution. That’s a really healthy sign for the whole community.
Host: Alex Chan I love that perspective. It’s a vote of confidence. Julian, this has been so insightful. I went from being a little intimidated by the 8.4 requirement to being genuinely excited for what it enables.
Guest: Julian Vance Same here, Alex. It’s going to be a fun couple of years watching this develop.
Host: Alex Chan Well, that’s all we have time for today on Allur. To recap: Pest 5 is coming July 28, 2026. It’s going to require PHP 8.4+. It’s faster, leaner, and it’s basically a love letter to the future of the PHP engine. If you want to learn more, definitely check out the official Pest PHP blog and start looking into those PHP 8.4 RFCs—especially property hooks!
Guest: Julian Vance Anytime, Alex. Thanks for having me!
Host: Alex Chan And thanks to all of you for tuning in to Allur. If you enjoyed this episode, subscribe on your favorite podcast app and leave us a review—it really helps the show. Stay curious, keep coding, and I’ll see you in the next one! Bye!
Tags
web development
php
testing
modernization
pest