Pest 4.x: Consolidating Unit and Browser Testing with Native Playwright Support

Host: Hey everyone, welcome back to Allur! I’m your host, Alex Chan, and I am so glad you’re joining me today. You know, if you’ve been in the PHP world for a while, you know the "Testing Tax." It’s that mental overhead we all pay when we build modern apps. You’ve got your beautiful Pest or PHPUnit suite for your logic, but then the second you need to test if a button actually *works* in a browser, you’re suddenly managing a whole different world. You’re pulling in Node.js, you’re wrestling with `package.json`, you’re setting up Cypress or Playwright in JavaScript... and honestly, it feels like living in two different houses at the same time. Host: Joining me today to help break all of this down is Leo Rossi. Leo is a Senior Staff Engineer who has spent years perfecting CI/CD workflows for massive Laravel applications. He’s been an early tester for the Pest 4.x beta and has some incredible insights into how this shift is affecting real-world dev teams. Leo, it’s great to have you on Allur! Guest: Thanks so much for having me, Alex! It’s a pretty wild time to be a PHP dev. I feel like we’ve been waiting for this "unified" dream for a decade, and actually seeing it land in Pest 4.x... yeah, it’s a bit of a "pinch me" moment. Host: Right? I mean, let’s start there. For the folks listening who maybe haven’t jumped into E2E testing because of the friction—explain the "before and after." What was the struggle like before June 25th? Guest: Oh, man. The struggle was real. Usually, you’d have your `tests/` directory for PHP, and then maybe a `tests_e2e/` or something similar for your JavaScript tests. You’d have to teach your whole team two languages. Even if they’re good at JS, it’s the *switching* that kills you. You’re writing a feature in PHP, you want to test the UI, and suddenly you’re thinking in `async/await` and Promises in Node. And the CI pipelines? Don't get me started. You’d have to install PHP, then install Node, then run `npm install`, then wait for the binaries... it was a mess. It literally doubled the chance of your build failing because of some random environment mismatch. Host: Exactly! It always felt like such a hurdle. So, enter Pest 4.x. The headline is "Native Playwright." When I first heard that, I thought, "Okay, is this just a PHP wrapper around a Node process?" But it’s more than that, isn't it? Guest: It really is. It’s not just a "shell exec" call. The team behind Pest really focused on making it feel native. You don't even need Node.js installed on your machine to run these browser tests anymore. When you run `pest install playwright`, it pulls down the necessary browser binaries directly. Then, inside your test file, you just use this incredibly fluent API. You might have a test where you use `$this->page->goto('localhost')`, and then right below it, you’re using standard Pest expectations. Host: That’s the part that blew my mind. I saw an example in the docs where you’re literally calling `expect($this->page->title())->toBe('My Application')`. It looks exactly like a unit test. Guest: Exactly! And that's the "aha moment." You’re using the same assertions, the same syntax, the same flow for a unit test as you are for a test that is *actually* spinning up a headless Chromium instance and clicking buttons. It’s... um, it’s honestly a little addictive once you start. You don't feel that "dread" of writing a browser test anymore because the API doesn't fight you. Host: I love that. "The API doesn't fight you." That should be the slogan! But okay, let's talk about the "real world." You’ve been moving some projects over to this. Have you noticed a performance difference? Because usually, PHP controlling a browser sounds like it might be... slow? Guest: You’d think so, right? But it’s actually surprisingly snappy. Because it’s leveraging Playwright’s direct communication protocols, the latency is minimal. But the *real* performance gain isn't necessarily in the execution of one test—it's in the total lifecycle. I was working on a project last week where our CI pipeline went from 12 minutes down to about 7. Host: Wow, that’s huge. Guest: Right? And most of that was just cutting out the Node.js setup and the separate "wait for dev server" steps that you usually need for something like Cypress. In Pest 4.x, it’s all orchestrated in one go. One `composer install`, one `pest` command. The efficiency of having a single dependency tree in `composer.json` is... well, it’s a dream for DevOps. Host: I can imagine. No more `npm audit` screaming at you while you're trying to fix a PHP bug! Guest: [Laughs] Precisely! One less thing to worry about. Host: So, let’s talk about the migration. If I’m a developer and I’ve got a bunch of tests in, say, Cypress or maybe even the old Playwright-JS. Is it worth the effort to rewrite them into Pest 4.x? That sounds like a lot of work. Guest: It’s a fair question. If you have a massive, stable suite of 500 Cypress tests, I wouldn't say "drop everything and rewrite it today." But for any *new* features? Absolutely. And honestly, the translation is easier than you think. The logic is the same: find a selector, click it, check the text. Host: I’m curious about the "struggles." It can’t be all sunshine and rainbows. Did you hit any walls when you first started playing with it? Guest: Yeah, actually. The biggest thing for me was breaking the habit of trying to use JavaScript-specific patterns. I kept trying to write `await` before my calls! I had to remind myself, "No, this is PHP. It’s synchronous, it’s clean." Also, when you're setting it up in a Docker environment, you do have to make sure your container has the right libraries for the browsers to run, which is a bit of a one-time configuration hurdle. But the `pest install playwright` command handles the bulk of it. Host: That makes sense. It's a mental shift as much as a technical one. Guest: Totally. But once you get over that hump of "Wait, I’m doing browser testing in PHP?", it’s like a weight is lifted. You realize how much energy you were wasting just managing the *tools* rather than writing the *tests*. Host: That is such a great point. We're here to build apps, not manage toolchains. Leo, before we wrap up, what’s your one big piece of advice for someone looking at Pest 4.x today? Guest: I’d say: start small. Don’t try to refactor your whole world. Just take one simple user flow—like a login or a contact form—and write it as a Pest browser test. See how it feels to have your unit tests and your browser tests in the same file or the same folder. Once you see that single green checkmark for both, you won’t want to go back. Host: I love that. It’s all about that "one green checkmark" feeling. Leo, thank you so much for joining us and sharing your experience. This was super enlightening! Guest: My pleasure, Alex! Thanks for having me. Host: And there you have it, folks. Pest 4.x is really looking like a turning point for the ecosystem. If you want to check it out, head over to the official Pest documentation—the release notes from June 25th cover all the new Playwright commands. It’s time to simplify those pipelines and get back to what we love: writing great code.