Stop 15 · TestingTopics · 8/8

E2E Testing

In short

End-to-end (E2E) tests run your whole app, frontend and backend together, in a real browser. They answer one question: can a user actually finish the flows that matter most?

End-to-End testing — verifying an entire user journey through the real, running application (often across frontend and backend together), the closest simulation of real usage.

The jaadu in a guard's cap waves a green flag from a new train passing signals.

Think of it like this

A trial run before the new train starts

Before a new train route opens, the railways run the whole route: board at the first station, cross every signal, reach the last stop. E2E tests do that full run on your app before real users board.

Watch it happen

An E2E run on a pull request

Push PR

Build app

Browser

User flow

Report

1/5You open a pull request. GitHub Actions starts the test job.

The big ideas

What you need to know

Test flows, not buttons

Few at the top of the pyramid

E2E tests are slow and costly to maintain. Keep many unit tests, fewer integration tests, and a handful of E2E.

Clean data each run

Seed a test database or create fresh users per test, so tests don't depend on each other.

Run them in CI

Run them on every pull request, so a broken checkout never reaches production.

See it in code

Walk through the code

1// playwright.config.ts2import { defineConfig } from "@playwright/test";3 4export default defineConfig({5  testDir: "./e2e",6  retries: process.env.CI ? 2 : 0,7  use: { baseURL: "http://localhost:3000", trace: "on-first-retry" },8  webServer: {9    command: "npm run build && npm run start",10    url: "http://localhost:3000",11    reuseExistingServer: !process.env.CI,12  },13});

1/3Tests live in ./e2e. On CI, a failing test retries twice before counting as failed.

webServer starts your real app before tests run. Traces are saved when a test is retried, so a CI failure comes with a full replay.

Save yourself the pain

Common mistakes

Oops

Writing E2E tests for every small UI detail.

Do this instead

Keep E2E for key user flows. Check details like button states with faster component tests.

Oops

Letting test B rely on the user that test A created.

Do this instead

Each test sets up its own data. Then tests can run in any order, or in parallel.

Your mission

Guard your most important flow

~45 min

Quick check

Why do teams keep only a small number of E2E tests compared to unit tests?

Go deeper

1Write one E2E test covering your app's most critical flow (e.g. signup then first action).
2Run E2E tests in CI before every deploy.
3Keep the E2E suite small and focused — they're valuable but slow and expensive to maintain.