Pest 4.7: Conquering Flaky Tests and Enforcing Code Architecture

Guest: Thanks so much for having me, Alex! I’ve been a long-time listener, so it’s actually a bit of a surreal "meta" moment to be on the other side of the mic. Host: Oh, I love that! Well, we’re glad to have you. So, Simon, let’s jump right in. Pest 4.7 just dropped, and the community is buzzing about it. In your view, why is this specific version such a big deal compared to just a standard incremental update? Guest: Yeah, it’s interesting because, on the surface, people see a version jump and think, "Oh, probably just some new helper methods." But 4.7 is really addressing what I call the "Professional Debt" of a project. It’s moving beyond just *running* tests to actually *managing* the health of the entire development lifecycle. Specifically, the native flaky test handling... Alex, I can't tell you how many hours—no, how many *days*—I’ve lost to flaky tests. Host: Oh, I think we’ve all been there. That feeling of seeing a red "X" on GitHub Actions at 4:55 PM on a Friday, you re-run it, it turns green, and you just… you just walk away and try not to think about it. But that’s dangerous, right? Guest: It’s incredibly dangerous! It’s like "The Boy Who Cried Wolf." If your tests fail randomly because of a weird network hiccup or a race condition in the database, eventually, your team starts ignoring *actual* failures. You stop trusting the suite. And once you lose trust in your tests, you stop writing them, or you stop looking at the CI. Host: So, how does Pest 4.7 actually tackle this? I saw there’s a new `--retry` flag? Guest: Exactly. It’s so simple but so effective. You can now just run `pest --retry=3`. If a test fails, Pest doesn’t immediately throw its hands up and kill the build. It says, "Okay, let me try that again." If it passes on the second or third try, it logs it as a "flaky" test but lets the build continue. Host: Interesting! But wait—doesn't that just hide the problem? Like, if I have a race condition, shouldn't I actually fix it instead of just retrying? Guest: (Laughs) That is the golden question! And honestly, the answer is: yes, you should fix it. But in the real world, some things are just outside your control. Maybe a third-party API you're hitting in a feature test is slightly unstable, or the CI environment has a momentary CPU spike. Pest 4.7 gives you the *breathing room* to get your work done while also flagging those tests. You can even set it up in your `pest.xml` file so it’s always on. It’s about pragmatism over perfection. Host: I love that. "Pragmatism over perfection." That’s a recurring theme in the PHP world lately. Speaking of perfection, though, let’s talk about the other big pillar: Architectural Assertions. This sounds… kind of intense. What are we actually testing here? Guest: This is actually my favorite part of the update. Usually, when we talk about architecture, we’re talking about "Vibes." Like, "Hey, please don't put database logic in the Controller, it's bad vibes." And then in a code review, you have to play the role of the "Architecture Police." Host: Ugh, and no one likes being that person. It feels so nitpicky. Guest: Exactly! It creates friction. With Pest 4.7, you can now write an actual test that says: "I expect my Controllers to NOT use my Repositories." Or "I expect my Domain layer to only use these three specific namespaces." Host: Wait, so it’s literally scanning the code structure? Can you give me an example of how that looks in the code? Guest: It’s beautiful. It’s just `test('architecture')->expect('App\Http\Controllers')->not->toUse('App\Repositories');`. That’s it. One line. If a junior developer—or even a senior developer in a rush—tries to import a Repository into a Controller, the test suite fails immediately. Host: Oh, wow. That’s an "aha moment" for me. It’s moving the architectural rules out of a "Style Guide" PDF that no one reads and into the actual test runner. Guest: Precisely. You can even enforce things like "All my Service classes must be final." You know, to prevent that deep, nested inheritance that becomes a nightmare to maintain. You just write `expect('App\Services')->toBeFinal();`. It’s like having a senior architect looking over your shoulder 24/7, but in a way that isn't annoying. Host: That is so powerful for onboarding. I can imagine a new dev joining a team and the test suite itself teaching them the rules of the house. "Oh, I can't do that here? Okay, let me find the right place for this code." Guest: Exactly. It turns the "No" into a learning moment. And it’s fast! People worry that scanning the whole codebase for architecture might slow things down, but the Pest team has done some incredible work under the hood. The performance improvements in 4.7 mean that even with these checks, the suite stays snappy. Host: You mentioned performance—is that just for the architectural stuff, or is the whole framework feeling a bit faster? Guest: It’s the whole framework. They’ve optimized how tests are discovered and executed. In my main project at ScaleFlow, we have about 2,000 tests, and after the upgrade to 4.7, we saw about a 15% drop in total execution time in our CI pipeline. That adds up! That’s fewer CI credits spent and more time actually coding. Host: 15% is not nothing! Especially when you're running those tests fifty times a day across a whole team. So, Simon, for someone listening who is maybe still on an older version of Pest, or—dare I say it—still just using raw PHPUnit, what’s your "sales pitch" for making the jump to 4.7 today? Guest: (Chuckles) Well, if you’re on an older version of Pest, the upgrade is a no-brainer. It’s backward compatible, and the benefits for CI stability alone are worth the five minutes it takes to run `composer update`. If you’re still on raw PHPUnit… look, I love PHPUnit, it’s the foundation. but Pest 4.7 is where the *joy* is. It’s the difference between writing code for a machine and writing code for a human. It makes you *want* to write tests. Host: "Writing code for a human." I think that’s the perfect way to wrap this up. Simon, thank you so much for joining us. This has been such an eye-opener. Where can people find you if they want to follow your work? Guest: You can find me on X (formerly Twitter) at @SimonVanceDev, or check out some of my open-source stuff on GitHub. And of course, go to pestphp.com to check out the new docs for 4.7!