Development

Why we're excited about Pest 4.

6 minutes

Well, Laracon US 2025 has been and gone, and honestly, there's one announcement that's got the whole team buzzing - Pest 4. Nuno Maduro's talk on Tuesday morning was the perfect way to kick off day one, and I have to say, what he showed us has completely changed how we're thinking about browser testing at Jump24.

Now, I know what you're thinking - "another testing framework update, here we go again" - but hear me out, because this one's different. Really different.

Our Cypress Reality Check

Let me start with a bit of context. We've been using Cypress for our browser testing for the past couple of years, and while it does the job, I'd be lying if I said it's been smooth sailing. Anyone who's worked with Cypress extensively will know exactly what I'm talking about.

The thing is, we're heavily PHP focused within the team we do enjoy JS but we shine with our PHP. Our team thinks in PHP, we debug in PHP, we dream in PHP (okay, maybe that's a bit much), but you get the point. So when it comes to writing our browser tests, suddenly we're context-switching to JavaScript, dealing with a completely different testing philosophy, and honestly, it feels a bit like having to switch languages mid-conversation.

Here's what a typical login test looks like for us in Cypress:

javascript

Copied

 1describe('User Login', () => {
 2  beforeEach(() => {
 3    cy.visit('/login')
 4  })
 5 
 6  it('should allow a user to log in with valid credentials', () => {
 7  cy.get('div.login-form form').within(() => {
 8        cy.get('input[name="username"]').type('cypress');
 9      cy.get('input[name="password"]').type('password123');
10        cy.get('div.login--submit button').click();
11      });
12 
13    cy.get('button[type="submit"]')
14      .click()
15 
16    cy.url().should('include', '/dashboard')
17    cy.contains('Welcome back').should('be.visible')
18  })
19})

describe('User Login', () => {
  beforeEach(() => {
    cy.visit('/login')
  })

  it('should allow a user to log in with valid credentials', () => {
  cy.get('div.login-form form').within(() => {
        cy.get('input[name="username"]').type('cypress');
      cy.get('input[name="password"]').type('password123');
        cy.get('div.login--submit button').click();
      });

    cy.get('button[type="submit"]')
      .click()

    cy.url().should('include', '/dashboard')
    cy.contains('Welcome back').should('be.visible')
  })
})

It works, don't get me wrong, but the pain points are real:

Our test suite takes a few hours to run our browser tests, we do have quite a few
We get intermittent failures that we can't reproduce locally
When something breaks, debugging across the PHP/JavaScript boundary is... well, let's just say it's not fun
The team has to remember Cypress-specific quirks like cy.wait(), dealing with async operations, and all those little gotchas that come with the territory

Plus, and this might sound petty, but having to maintain two different testing configurations feels like unnecessary overhead. We've got our Pest setup for unit and feature tests, then completely separate Cypress config for browser tests.

Enter Pest 4 - Game Changer Territory

So when Nuno started talking about browser testing coming to Pest 4, I'll admit I was immediately interested. But when he showed the demo, that's when it really clicked for me.

Imagine writing that same login test, but like this:

php

Copied

 1describe('User Login', function () {
 2    it('should allow a user to log in with valid credentials', function () {
 3        $this->browser()
 4            ->visit('/login')
 5            ->type('input[type="email"]', 'test@example.com')
 6            ->type('input[type="password"]', 'password123')
 7            ->click('button[type="submit"]')
 8            ->assertUrlContains('/dashboard')
 9            ->assertSee('Welcome back');
10    });
11});

describe('User Login', function () {
    it('should allow a user to log in with valid credentials', function () {
        $this->browser()
            ->visit('/login')
            ->type('input[type="email"]', 'test@example.com')
            ->type('input[type="password"]', 'password123')
            ->click('button[type="submit"]')
            ->assertUrlContains('/dashboard')
            ->assertSee('Welcome back');
    });
});

Look at that! It's PHP, it follows the same patterns as our existing tests, and most importantly, the whole team can read it without having to shift mental gears.

But here's the really clever bit - it's powered by Playwright under the hood. For those who haven't been following the browser testing space closely, Playwright is essentially the new kid on the block that's been eating Selenium's lunch. It's fast, reliable, and handles modern web apps much better than the older tools. It's a tool we've been looking at as a replacement for Cypress on our newer projects.

The Technical Bits That Got Me Excited

During the talk, Nuno also mentioned parallel testing capabilities, and this is where things get really interesting for us. Our current Cypress setup runs tests sequentially, which is part of why it takes so bloody long. With Pest 4's parallel capabilities via Playwright, we should see a massive improvement in test execution times.

The device testing features also caught my eye. Right now, if we want to test how our app behaves on different screen sizes, we're doing this in Cypress:

javascript

Copied

1describe('Responsive Design', () => {
2  it('should work on mobile devices', () => {
3    cy.viewport('iphone-x')
4    cy.visit('/dashboard')
5    cy.get('.mobile-menu-toggle').should('be.visible')
6  })
7})

describe('Responsive Design', () => {
  it('should work on mobile devices', () => {
    cy.viewport('iphone-x')
    cy.visit('/dashboard')
    cy.get('.mobile-menu-toggle').should('be.visible')
  })
})

With Pest 4, it looks like this becomes much more intuitive:

php

Copied

1it('should work on mobile devices', function () {
2    $this->browser()
3        ->iPhone15()
4        ->visit('/dashboard')
5        ->assertSee('.mobile-menu-toggle');
6});

it('should work on mobile devices', function () {
    $this->browser()
        ->iPhone15()
        ->visit('/dashboard')
        ->assertSee('.mobile-menu-toggle');
});

The syntax just feels more natural, more in line with how we think about testing.

What This Means for Our Projects

I've been thinking about this quite a bit since the conference, and I reckon this could fundamentally change how we approach testing on our projects. Instead of having this artificial split between backend tests (written in PHP with Pest) and frontend tests (written in JavaScript with Cypress), we could have everything in one place.

Think about it - unit tests, feature tests, and browser tests all running in the same framework, all written in the same language, all following the same patterns. That's the kind of consistency that makes development teams happy.

We've got a few projects coming up where I'm definitely going to push for using Pest 4 from the start. The time savings alone from not having to context-switch between testing frameworks should be worth it.

The Release Date Dance

Nuno mentioned that Pest 4 is expected to release on August 21, 2025, at Laravel Live Denmark 2025. I have to say, that feels like perfect timing for us. We've got a couple of projects that are due to kick off around September, so if all goes to plan, we should be able to start using it in anger fairly quickly.

I'm already planning to set aside some time in late August to play around with the beta (assuming there is one) and start thinking about migration paths for our existing projects.

Our Cypress Migration Strategy

We're not planning to throw away our existing Cypress tests overnight - that would be madness. But I am thinking about a gradual migration approach. Maybe we start by rewriting our most problematic Cypress tests (you know, the flaky ones that randomly fail in CI) and see how they perform in Pest 4.

If the performance improvements are as good as they sound, then we can start planning a more comprehensive migration for our larger projects.

The Bottom Line

Look, I've been burned by overhyping new tools before, but this feels different. It's not trying to solve a problem that doesn't exist - it's addressing real pain points that we deal with every day.

The fact that Pest has gone from 18 million installs to 39 million installs in just one year tells you everything you need to know about how the community feels about Nuno's work. And if the browser testing features are as good as they looked in the demo, I suspect we'll see that number climb even higher.

For us at Jump24, anything that lets us write better tests faster while staying in our PHP comfort zone is a win. And if it makes our CI pipeline faster and more reliable in the process, even better.

I'll definitely be writing a follow-up post once we get our hands on Pest 4 and can share some real-world experiences with it. Until then, August 21st can't come soon enough!

What do you think? Are you planning to give Pest 4 a go when it launches? I'd love to hear how other teams are thinking about integrating these browser testing capabilities into their workflow.