Testing Laravel Applications with Pest: Unit, Feature, and Browser Tests

Testing Laravel applications with Pest stopped being a stylistic choice a while ago — Pest is the default testing framework for new Laravel applications, and the ecosystem\'s energy (plugins, architecture testing, browser testing) has followed it. Built on top of PHPUnit, it keeps everything you know about Laravel\'s testing helpers while replacing class boilerplate with a functional syntax that makes tests faster to write and — more importantly — faster to read. This post covers how to structure a Pest suite that actually pays for itself.

The shape of a Pest test

A Pest test is a closure with a description. No class, no method-name camelCase encoding of the behavior, no $this->assertEquals ceremony:

it('calculates the order total including tax', function () {
    $order = Order::factory()
        ->has(OrderItem::factory()->count(2)->state(['price_cents' => 1000]))
        ->create(['tax_rate' => 0.1]);

    expect($order->total())->toBe(2200);
});

The expect() API chains naturally — expect($user->isAdmin())->toBeTrue(), expect($response->json('data'))->toHaveCount(3)->each->toHaveKey('id') — and failure messages quote the expectation as written. Shared setup goes into beforeEach(), and suite-wide configuration lives in tests/Pest.php, where new Laravel apps already bind the base TestCase and the RefreshDatabase trait to the Feature directory. That one file replaces the boilerplate header of every test in the suite.

Unit tests: fast, isolated, and honest about scope

Reserve tests/Unit for code that genuinely does not need the framework booted: value objects, calculators, parsers, pure services. These tests run in microseconds and their speed is the point — a suite you run on every save has to be fast enough that you actually do. The moment a "unit" test needs a database, a container binding, or config, move it to Feature and stop fighting; Laravel\'s sweet spot is the feature test anyway. A useful discipline is to design domain logic so it can be unit tested: a ShippingCalculator that takes plain values is testable in isolation, while one that reaches into request state and Eloquent globals is not.

Feature tests: where Laravel testing earns its keep

Feature tests boot the framework, hit real routes, and run real queries against a test database — which means they test your routing, middleware, validation, authorization, and persistence in one pass:

it('prevents guests from creating projects', function () {
    $this->postJson('/api/projects', ['name' => 'Skunkworks'])
        ->assertUnauthorized();
});

it('creates a project for an authenticated user', function () {
    $user = User::factory()->create();

    $this->actingAs($user)
        ->postJson('/api/projects', ['name' => 'Skunkworks'])
        ->assertCreated()
        ->assertJsonPath('data.name', 'Skunkworks');

    $this->assertDatabaseHas('projects', [
        'name' => 'Skunkworks',
        'owner_id' => $user->id,
    ]);
});

Three practices keep feature suites trustworthy:

• Use factories, and use their states. A named state like User::factory()->suspended() documents the domain and keeps tests readable. Never seed shared fixtures that every test implicitly depends on — that is how suites become order-dependent.
• Fake the outside world. Mail::fake(), Queue::fake(), Storage::fake(), Event::fake(), and Http::fake() swap infrastructure for recorders you can assert against: Queue::assertPushed(SyncOrderToErp::class). Http::preventStrayRequests() turns any unfaked outbound HTTP call into a test failure, which catches the integration you forgot to stub.
• Assert outcomes, not implementation. Asserting that a specific method was called welds the test to today\'s code. Asserting the response, the database row, and the dispatched job leaves you free to refactor.

Pest\'s datasets deserve special mention for validation testing, where the same test logic applies to many inputs:

it('rejects invalid registration input', function (array $input, string $field) {
    $this->postJson('/register', $input)
        ->assertJsonValidationErrors($field);
})->with([
    'missing email' => [['password' => 'secret-123'], 'email'],
    'short password' => [['email' => 'a@b.com', 'password' => '123'], 'password'],
]);

Architecture tests: cheap guardrails

Pest\'s architecture testing plugin asserts structural rules that code review keeps missing:

arch('controllers do not touch Eloquent directly')
    ->expect('App\Http\Controllers')
    ->not->toUse('Illuminate\Database\Eloquent\Builder');

arch('no debugging statements ship')
    ->expect(['dd', 'dump', 'ray'])
    ->not->toBeUsed();

These run in milliseconds, and the preset arch()->preset()->laravel() covers common conventions out of the box. They are the cheapest tests you will ever write relative to the class of bug they prevent.

Browser tests: the expensive tier, used sparingly

Some behavior only exists in a real browser: JavaScript-driven UIs, Livewire interactions, multi-step flows with redirects and modals. Laravel has two answers — the long-standing Dusk, and the newer Pest browser testing plugin, which brings Playwright-powered browser tests into the same Pest syntax as the rest of your suite, with real-browser execution and smart waiting built in. Whichever you choose, the economics are the same: browser tests are an order of magnitude slower and flakier than feature tests, so spend them only on the critical paths — registration, login, checkout, the one wizard your revenue depends on — and let feature tests carry everything else. If a behavior can be verified with an HTTP-level Livewire or JSON assertion, do that instead.

Making the suite sustainable

1. Run tests in parallel. php artisan test --parallel shards the suite across processes with separate databases; large suites drop from minutes to seconds.
2. Use SQLite in memory when you can, your production engine when it matters. In-memory SQLite is fast, but tests relying on MySQL-specific behavior (JSON columns, full-text search, strict modes) should run against MySQL in CI. Discovering a dialect difference in production is the expensive way.
3. Track coverage as a trend, not a target. --coverage --min=80 in CI stops erosion; chasing 100 percent produces brittle tests of getters. Pest\'s --profile flag also lists your slowest tests, which is where suite time goes to die.
4. Write the regression test first when fixing bugs. A failing test that reproduces the bug is both the proof of the fix and the guarantee it stays fixed.

Closing thoughts

The best Laravel test suites in 2026 share a profile: a thin, fast unit layer for pure logic; a broad feature layer using factories and fakes that covers routes, policies, and persistence; a handful of architecture tests enforcing conventions; and a small set of browser tests guarding the flows that pay the bills. Pest\'s contribution is lowering the friction at every layer — and friction, more than ideology, is what determines whether tests actually get written.