Programing
Pest 4’s Playwright Integration: Unified Browser and Visual Testing
Published:
•
Duration: 5:38
0:00
0:00
Transcript
Guest: Hey Alex! Thanks for having me. It’s an exciting time to be writing PHP, honestly. I feel like we’re finally getting the toys the JS world has had for years, but with that signature Laravel-style polish.
Host: Right? It feels like we’re finally catching up and, in some ways, maybe even leapfrogging the DX. So, let’s start with that big number—39 million installs. Why do you think Pest has become the "definitive" choice now?
Guest: It’s funny, I remember when Pest first came out, some people were like, "Oh, it’s just a wrapper around PHPUnit, do I really need it?" But those 39 million installs tell a different story. It’s about cognitive load. When you’re writing Pest, the code reads like a sentence. It’s expressive. And I think what Nuno and the team realized is that if you make testing fun—or at least, significantly less annoying—people actually do it. Pest 4 isn’t just a version bump; it’s a statement that says your testing suite shouldn’t be five different tools held together by duct tape and a messy CI config.
Host: "Duct tape and a messy CI config"... I feel seen, Marcus. That’s literally every project I worked on in 2022. Speaking of tools, let’s talk about Playwright. Pest 4 has integrated it as the core engine for browser testing. Why Playwright and not, say, sticking with Selenium or Laravel Dusk?
Guest: Oh man, where do I start? Selenium… look, it served us well, but it’s heavy. It’s flaky. We’ve all had those CI runs where a test fails for no reason, you hit "retry," and it passes. That’s the "flakiness" that kills developer trust. Playwright, which is Microsoft’s baby, is just… it’s fast. It handles Chromium, WebKit, and Firefox natively. But the real "aha moment" for me with the Pest integration was the "auto-wait" functionality.
Host: Tell me more about that. Is that the fix for those "Wait, the button hasn't loaded yet" errors?
Guest: Exactly! In the old days—actually, even yesterday for some people—you’d have to manually tell the test to `pause(500)` or `waitForSelector`. It was guesswork. Playwright is smarter. It waits for the element to be "actionable." So, in Pest 4, you just write `$this->browse()->click('Submit')` and it just… works. It waits for the animations to finish, it waits for the JS to hydrate. It makes the tests feel robust.
Host: That sounds like a dream. But the thing that really caught my eye in the announcement was the "JavaScript Divide." I’ve definitely felt that pain of having a `tests/Feature` folder in PHP and then a totally separate `cypress` folder with its own `node_modules`. How does Pest 4 actually kill that?
Guest: It brings everything into one language. One syntax. You don't need a `package.json` just to test your UI anymore. You write your browser test in a `.php` file, just like your unit tests. You can even use the same mocks! If you have a service you mocked in PHP, your browser test can technically respect that environment because it’s all running under the same umbrella.
Host: That has to be a massive boost for velocity. But what about visual testing? That’s the "Advanced Visual Regression" part. I’ve used tools like Percy before, and they can get pretty pricey for smaller teams. How is Pest handling this natively?
Guest: This is the game-changer. Visual regression is basically taking a screenshot of your site and saying, "This is the baseline. If a single pixel changes tomorrow, tell me." Pest 4 has this built-in now with `assertScreenshot()`.
Host: Wait, so if I intentionally change the UI—like we do a total redesign—is it a pain to update those images?
Guest: Not at all. That’s the beauty of the CLI integration. You just run a command—I think it’s like `--update-snapshots`—and it replaces the old baselines with the new ones. It keeps the "UI drift" in check without you having to manually look at every page every time you push code.
Host: I can imagine that saves so much time in QA. I’ve definitely pushed "logic" changes that accidentally broke a layout on a page I wasn't even looking at.
Guest: Oh, we all have. It’s the "butterfly effect" of CSS. You change a padding in the footer and suddenly the contact form is unusable on mobile. Pest 4 catches that in your local terminal before it ever touches GitHub.
Host: Speaking of GitHub, how does this affect CI/CD? Is it a nightmare to set up Playwright in a GitHub Action?
Guest: It’s actually simpler. Think about your old pipeline: You’d have to install PHP, then install Node, then run `npm install`, then maybe start a separate Selenium server. Now, you’re basically just running your Pest command. Because it’s unified, your Docker images can be lighter, and your pipeline is just one sequence. It reduces that "green on local, red on CI" frustration because the environment is so much more controlled.
Host: That is a huge relief. I think a lot of us spend more time fighting our YAML files than writing actual code.
Guest: *Laughs* Totally.
Host: So, if someone is listening and they’re still on PHPUnit or maybe they’re using an older version of Pest, what’s your advice? Is the jump to Pest 4 and Playwright a steep climb?
Guest: Honestly, the DX is so good that the climb feels more like an escalator. The documentation for the new `browse()` API is incredibly intuitive. My advice is to start with "Smoke Testing." Don't try to test every single button on day one. Just write one test that logs in and visits the dashboard. Once you see that browser window pop up and run through your app in seconds, you’ll be hooked.
Host: I love that. "Smoke testing" as a gateway drug to full coverage. Well, Marcus, this has been incredibly enlightening. It really feels like Pest 4 is moving from just a "testing tool" to a full-on "quality assurance platform."
Guest: Absolutely. It’s about confidence. And Pest 4 gives you that in spades.
Guest: Thanks for having me, Alex!
Host: And to our listeners, if you want to dive deeper into Pest 4, head over to pestphp.com or check out the latest updates on Laravel News. We’ll have links to the documentation and some of the code snippets Marcus mentioned in our show notes.