Testing

01The test pyramid

Think of checking a car. You test each part on a bench (unit tests): many, fast, cheap. You test systems together, the engine with the gearbox (integration and feature tests): fewer, slower. Then you take the whole car for a drive (end-to-end tests): few, slowest, but closest to reality. The pyramid says: many unit tests at the bottom, a solid layer of integration tests, a thin layer of E2E on top. For backend APIs many teams prefer a 'trophy' shape, with the biggest layer being feature tests that call real endpoints with a real test database, because that is where most bugs live. Either way: fast tests run constantly, slow tests cover only critical journeys.

• Unit: one function or class, no database or network.
• Feature / integration: HTTP request in, database and response checked.
• E2E: a real browser or device going through the real UI and API.

02PHPUnit and Pest for Laravel

Laravel ships with PHPUnit and Pest (a friendlier syntax on top of PHPUnit). Feature tests send HTTP requests to your app in memory and assert on the response, the database and side effects. Use the RefreshDatabase trait so each test starts clean; run tests against the same database engine as production (MySQL or PostgreSQL), because SQLite behaves differently in edge cases. Factories create realistic models in one line, with states for variations like a paid order or a blocked user. Laravel's fakes replace external effects: Queue::fake, Mail::fake, Notification::fake, Event::fake and Http::fake let you assert something was sent without sending it.

1it('lets a customer place an order', function () {
2    Queue::fake();
3    $user = User::factory()->create();
4    $product = Product::factory()->create(['price' => 2500]);
5 
6    $this->actingAs($user)
7        ->postJson('/api/v1/orders', ['items' => [['product_id' => $product->id, 'qty' => 2]]])
8        ->assertCreated()
9        ->assertJsonPath('data.total', 5000);
10 
11    $this->assertDatabaseHas('orders', ['user_id' => $user->id, 'total' => 5000]);
12    Queue::assertPushed(SendOrderConfirmation::class);
13});

03Jest, Vitest and node:test for TypeScript

In the JavaScript world, Vitest is the modern default for Vite-based and most new TypeScript projects: fast, ESM-native and Jest-compatible. Jest is still common, especially in React Native and older codebases. Node also has a built-in runner, node:test, with no dependencies at all. For NestJS, use the testing module to build a slice of the app and override providers with fakes; for API tests, supertest sends requests to the app. Test pure logic (pricing, permissions, date rules) with many small unit tests, and test endpoints against a real PostgreSQL in Docker or Testcontainers rather than mocking the ORM.

1import { describe, it, expect } from 'vitest';
2import { applyPromotion } from './pricing';
3 
4describe('applyPromotion', () => {
5  it('never discounts below zero', () => {
6    expect(applyPromotion({ subtotal: 1000 }, { type: 'fixed', amount: 1500 }).total).toBe(0);
7  });
8 
9  it('applies percentage to subtotal only, not delivery', () => {
10    const r = applyPromotion({ subtotal: 10_000, delivery: 500 }, { type: 'percent', amount: 10 });
11    expect(r.total).toBe(9_500);
12  });
13});

04Playwright for end-to-end tests

Playwright drives real Chromium, Firefox and WebKit browsers. It auto-waits for elements, so tests are far less flaky than older tools, and it records traces with screenshots and network logs when something fails. Write E2E tests for a handful of journeys that make or lose money: sign-in, add to cart and checkout, a core admin action. Select elements by role and visible text, the way users find them, not by CSS classes. Seed the data each test needs through the API or a fixture rather than clicking through setup screens, and run the suite against a staging-like environment with external services stubbed.

1import { test, expect } from '@playwright/test';
2 
3test('guest can check out', async ({ page }) => {
4  await page.goto('/products/sample-product');
5  await page.getByRole('button', { name: 'Add to cart' }).click();
6  await page.getByRole('link', { name: 'Cart' }).click();
7  await page.getByRole('button', { name: 'Checkout' }).click();
8  await page.getByLabel('Phone').fill('+10000000000');
9  await page.getByRole('button', { name: 'Place order' }).click();
10  await expect(page.getByRole('heading', { name: 'Thank you' })).toBeVisible();
11});

05Mocking external services and fixtures

Your tests should never call a real payment gateway, SMS provider or ERP. Replace them at the boundary: wrap each integration in your own client class, and in tests swap it for a fake or stub its HTTP calls (Http::fake in Laravel, MSW or nock in Node). Record realistic responses, including errors and timeouts, as fixtures so you test failure paths too. Do not mock what you own, like your own services or the database; mocking too much produces tests that pass while production breaks. Factories build test data with sensible defaults, so each test states only what matters to it. Keep tests independent: no shared state, no required order.

06Testing in CI and what to test first

Run lint, type checks and tests on every pull request, and block merging when they fail. Use a real database service in the CI job, run tests in parallel, and cache dependencies so feedback arrives in minutes. Run E2E on main or nightly if it is slow. In a real product with no tests, do not aim for coverage numbers. Start where a bug costs most: money (checkout totals, discounts, refunds, payment callbacks), permissions and tenant isolation, and state machines like order status. Then add a test for every bug you fix, so it never returns. Coverage grows naturally where it matters.

1# .github/workflows/test.yml (excerpt)
2jobs:
3  test:
4    runs-on: ubuntu-latest
5    services:
6      postgres:
7        image: postgres:17
8        env: { POSTGRES_PASSWORD: postgres, POSTGRES_DB: app_test }
9        ports: ["5432:5432"]
10    steps:
11      - uses: actions/checkout@v4
12      - uses: pnpm/action-setup@v4
13      - uses: actions/setup-node@v4
14        with: { node-version: 24, cache: pnpm }
15      - run: pnpm install --frozen-lockfile
16      - run: pnpm typecheck && pnpm lint && pnpm test

07Fast, isolated database tests

Database tests are the most valuable backend tests and the easiest to make slow. Isolation strategies, from fastest: wrap each test in a transaction and roll it back (Laravel's RefreshDatabase does this after migrating once per run, and LazilyRefreshDatabase skips migration when a test never touches the database); truncate tables between tests when code under test opens its own transactions or connections; or recreate the database, which is slowest. Run in parallel: php artisan test --parallel gives each process its own database with a suffix, so tests do not collide. In Node, Testcontainers starts a real PostgreSQL in Docker per test run, so CI and laptops use the same engine and version as production. Speed tricks: keep the database on tmpfs in CI, migrate once and clone from a template database in PostgreSQL, and never sleep in tests.

1import { before, after } from 'node:test';
2import { execSync } from 'node:child_process';
3import { PostgreSqlContainer, type StartedPostgreSqlContainer } from '@testcontainers/postgresql';
4 
5let pg: StartedPostgreSqlContainer;
6 
7before(async () => {
8  pg = await new PostgreSqlContainer('postgres:17').start();
9  process.env.DATABASE_URL = pg.getConnectionUri();
10  execSync('npx prisma migrate deploy', { stdio: 'inherit' });
11});
12 
13after(async () => {
14  await pg.stop();
15});

08Beyond examples: property-based and mutation testing

Example tests check the cases you thought of. Property-based testing checks rules against hundreds of generated inputs: instead of 'a 10% discount on 1,000 gives 900', you state 'for any subtotal and any percentage from 0 to 100, the total is never negative and never above the subtotal'. Libraries such as fast-check for TypeScript generate inputs and, when a case fails, shrink it to the smallest failing example. It shines for pricing, rounding, parsing and date logic. Mutation testing measures how good your tests are rather than how much code they run. Tools such as Infection for PHP and Stryker for JavaScript make small changes to your code, for example turning >= into >, and rerun the tests. If the tests still pass, that mutant survived, which shows an assertion is missing. Coverage says a line ran; mutation score says a test would notice if it were wrong.

1import fc from 'fast-check';
2import { test, expect } from 'vitest';
3import { applyPromotion } from './pricing';
4 
5test('percentage promotions stay within 0 and the subtotal', () => {
6  fc.assert(
7    fc.property(
8      fc.integer({ min: 0, max: 10_000_000 }),
9      fc.integer({ min: 0, max: 100 }),
10      (subtotal, percent) => {
11        const { total } = applyPromotion({ subtotal }, { type: 'percent', amount: percent });
12        expect(total).toBeGreaterThanOrEqual(0);
13        expect(total).toBeLessThanOrEqual(subtotal);
14      },
15    ),
16  );
17});

09Architecture and contract tests

Some rules are about structure, not behaviour, and tests can guard them too. Pest's architecture testing lets you assert that controllers never use the DB facade, that the domain layer never imports HTTP classes, or that no debug functions such as dd() reach production; it also ships presets for common rule sets. Between apps and services, contract tests catch the most expensive class of bug: one side changes a field the other depends on. With consumer-driven contracts (Pact is the best-known tool), the consumer records what it expects from the provider, and the provider's CI verifies it still satisfies every consumer. A lighter option is validating real API responses in feature tests against your OpenAPI schema. Both are much faster and more precise than full end-to-end suites for proving that two systems still agree.

1// tests/ArchTest.php (Pest)
2arch()->preset()->php();       // e.g. no dd(), dump() or var_dump()
3arch()->preset()->security();  // flags eval(), md5(), sha1() and similar
4 
5arch('controllers do not query the database directly')
6    ->expect('App\Http\Controllers')
7    ->not->toUse('Illuminate\Support\Facades\DB');
8 
9arch('domain does not depend on HTTP')
10    ->expect('App\Domain')
11    ->not->toUse('Illuminate\Http');

10Testing time, retries and concurrency

The bugs that reach production are often about time and repetition: a subscription that expires one second early, a job that double-sends when retried, two requests that oversell stock. Test them on purpose. Freeze or move time instead of waiting: Laravel's travelTo() and travel(), Carbon::setTestNow(), or vi.useFakeTimers() and vi.setSystemTime() in Vitest. Test boundaries, the second before and after a deadline, and time zones around midnight and daylight saving changes. For idempotency, run the same job or webhook twice and assert one effect. For race conditions, a unit test with mocks proves nothing; fire real concurrent requests against a real database, for example with Promise.all in an integration test or a short k6 script, and assert that the invariant, such as stock never below zero, still holds.

1it('expires a subscription exactly at its end time', function () {
2    $sub = Subscription::factory()->create(['ends_at' => '2026-03-01 00:00:00']);
3 
4    $this->travelTo('2026-02-28 23:59:59');
5    $this->artisan('subscriptions:expire')->assertSuccessful();
6    expect($sub->fresh()->status)->toBe(SubscriptionStatus::Active);
7 
8    $this->travelTo('2026-03-01 00:00:01');
9    $this->artisan('subscriptions:expire')->assertSuccessful();
10    expect($sub->fresh()->status)->toBe(SubscriptionStatus::Expired);
11});
12 
13it('creates one invoice even if the job runs twice', function () {
14    $order = Order::factory()->paid()->create();
15    GenerateInvoice::dispatchSync($order->id);
16    GenerateInvoice::dispatchSync($order->id);
17    expect(Invoice::where('order_id', $order->id)->count())->toBe(1);
18});