Pest 5 for Laravel 13: what's new and how to upgrade safely

Pest 5, released on 28 July 2026, is the biggest Pest update since browser testing arrived in Pest 4. For Laravel 13 teams the headline features are test impact analysis (TIA), which reruns only the tests affected by your change, an Agent plugin that lets AI coding agents verify behaviour inside your real test environment, and evals for testing LLM features. Upgrading needs PHP 8.4 and a small composer.json change.

This update summarises what changed and how to adopt it. It is based on the Pest 5 announcement, the Pest documentation and the Pest GitHub releases as of 10 October 2026, when the latest version was Pest 5.3.1.

Pest 5 at a glance

Requirements: check PHP first

Pest 5 requires PHP 8.4 or newer and is built on PHPUnit 13. The Laravel plugin, pestphp/pest-plugin-laravel 5.x, requires PHP 8.4 and laravel/framework 13.23 or later. Laravel 13 itself still supports PHP 8.3, so an application can be on a current Laravel release and still be unable to install Pest 5.

Pest's support policy keeps Pest 4 (PHP 8.3+) on bug fixes until 28 July 2027, so teams stuck on PHP 8.3 are not forced to move yet. Pest 3 stopped receiving bug fixes on 21 August 2026.

How to upgrade a Laravel 13 app

1. Confirm PHP 8.4+ locally, in CI and anywhere tests run: php -v.
2. Update Laravel to at least 13.23: composer update laravel/framework.
3. Change the constraints in composer.json and update all Pest-maintained plugins to ^5.0:

composer require --dev pestphp/pest:^5.0 pestphp/pest-plugin-laravel:^5.0 --with-all-dependencies

# If you use them, move these to ^5.0 as well
# pestphp/pest-plugin-browser, pestphp/pest-plugin-arch, pestphp/pest-plugin-type-coverage

The --with-all-dependencies flag lets Composer move phpunit/phpunit from 12.x (the Laravel 13 skeleton's default) to 13.x. Pest's upgrade guide lists no Pest-specific breaking changes beyond the PHP requirement, but rates the PHPUnit 13 move as a medium-likelihood source of breakage, so read the PHPUnit 13 changelog if you use PHPUnit APIs directly in tests.

Then run the full suite once without any new flags and fix failures before trying the new features:

./vendor/bin/pest --parallel

Test impact analysis: the feature you will use daily

TIA records a dependency graph on the first run: for each test, which files it executed. On later runs it reruns only tests whose dependencies changed and replays cached results for the rest, including coverage numbers.

./vendor/bin/pest --parallel --tia

Recording needs a coverage driver, PCOV or Xdebug. Without one, TIA does not run. To enable it for local runs only, add this to tests/Pest.php:

pest()->tia()->locally();

Some changes deliberately trigger a full rerun, because Pest cannot prove which tests depend on them: config files such as config/app.php, .env files, phpunit.xml, tests/Fixtures and snapshots. Changes to composer.lock, vite.config.* or Node lockfiles rebuild the graph. Comment-only and formatting edits run no tests at all, since comments and whitespace are stripped before hashing. If results ever look wrong, re-record with --tia --fresh.

The graph lives outside the project by default, in ~/.pest/tia/, keyed by your git remote. Do not commit it. Pest's documentation is explicit that the main CI pipeline should not use --tia: run the whole suite with ./vendor/bin/pest --ci on a clean checkout. A separate workflow can record a shared baseline on pushes to main, which developers fetch with pest()->tia()->baselined(). GitHub Actions baselines arrived in 5.0 and GitLab CI baselines in 5.2.

The Agent plugin

AI coding assistants can already run tests, but they often "verify" a change by loading a page in a browser, which cannot see queued jobs, sent mail or database rows. The Agent plugin gives them a better probe. Install it as a dev dependency:

composer require pestphp/pest-plugin-agent --dev

./vendor/bin/pest --agent='$user = \App\Models\User::factory()->create(); $this->actingAs($user)->get("/dashboard")->assertOk();'

Pest writes the snippet into a temporary test named verify, runs it with the traits registered in tests/Pest.php (such as RefreshDatabase), reports a pass or fail and deletes the file. Things to know before relying on it:

• Use single quotes so your shell does not expand $variables.
• Use fully qualified class names; the generated file has no use imports.
• beforeEach() hooks attached to directories with uses()->in() do not run, so put setup in the snippet.
• It is a verification probe, not a replacement for permanent feature tests.

With the Browser plugin and Playwright installed, the same option can drive a real browser, for example --agent='visit("/")->assertSee("Welcome");'.

Evals for LLM features

If your Laravel app calls a language model, ordinary assertions are not enough: answers vary between runs. The Evals plugin extends expect() with scorers. Deterministic ones include toContain(), toMatch(), toBeJson(), toHaveToolCalls() and toFollowTrajectory(); AI-judged ones include toBeRelevant(), toBeSafe(), toBeCorrect(), toBeSimilar() and toSatisfy(), each with a threshold that defaults to 0.7.

use App\Agents\SupportReplyAgent;

it('answers refund questions with the policy link', function (): void {
    expect(SupportReplyAgent::class)
        ->prompt('How do I get a refund for an annual plan?')
        ->toContain('/legal/refunds')
        ->toBeRelevant();
});

Evals are skipped on a normal run, so they never call a paid API by accident. Run them with ./vendor/bin/pest --evals or by setting PEST_EVALS in a scheduled CI job. AI scorers need a judge and an embeddings driver; by default these use the laravel/ai package with an OpenAI key, but the drivers are pluggable, so you can use another provider or a stub. Keep keys in CI secrets, never in phpunit.xml.

PHPStan, Rector and sharding

Two first-party plugins improve the test code itself. pestphp/pest-plugin-phpstan teaches PHPStan about it(), expect() and $this in closures, and flags impossible expectations such as expect(10)->toStartWith('1'). pestphp/pest-plugin-rector adds refactoring sets, for example turning expect(count($array))->toBe(5) into expect($array)->toHaveCount(5):

// rector.php
use Pest\Rector\Set\PestSetList;
use Rector\Config\RectorConfig;

return RectorConfig::configure()
    ->withPaths([__DIR__.'/tests'])
    ->withSets([
        PestSetList::CODING_STYLE,
    ]);

Preview with vendor/bin/rector process --dry-run before applying. For CI, time-balanced sharding replaces count-based splitting. Generate timings once with ./vendor/bin/pest --update-shards, commit tests/.pest/shards.json, then run --shard=1/4 to --shard=4/4 on four machines so they finish at roughly the same time.

Gotchas and what to do next

• PHP 8.4 everywhere. A developer or CI image on PHP 8.3 will fail at composer install. Upgrade images first.
• Coverage driver for TIA. Install PCOV in local and baseline environments; production images do not need it.
• Do not trust TIA as a merge gate. Keep the full suite on CI.
• Cost control for evals. Run them on a schedule or on changes to prompts and agents, not on every push.
• Agent snippets touch your test database. Make sure .env.testing or phpunit.xml points at a disposable database.

A sensible order is: move CI and local environments to PHP 8.4, upgrade to Pest 5 and PHPUnit 13 with the suite unchanged, enable pest()->tia()->locally(), then add sharding and the static analysis plugins. Add the Agent and Evals plugins only when you use AI agents or ship LLM features.