Unit tests prove a function works. End-to-end tests prove the product works. They drive the real app the way a user would, from the first click to the final result, and catch the breakages that only show up when every piece runs together. They are also the slowest and most fragile tests you own, so the skill is using them sparingly and well.
What is end-to-end testing?#
End-to-end (E2E) testing verifies a complete user flow through the whole running system: UI, backend, database, and any third-party services, all live. Instead of checking one part in isolation, it confirms a real journey works start to finish, like signing up, logging in, and completing a purchase.
How it differs from other tests#
E2E sits at the top of the testing pyramid: widest scope, slowest to run, fewest in number.
| Level | Scope | Speed | Count |
|---|---|---|---|
| Unit | One piece of logic | Very fast | The most |
| Integration | A few parts together | Medium | Fewer |
| End-to-end | The whole app, live | Slow | The fewest |
The rule: push a check as low as it can go, and reserve E2E for the few flows that must work for a user.
What a good E2E test covers#
Critical journeys only, the paths where failure costs you customers or revenue: auth, checkout, signup, core create-and-save. Each test acts like a user: it navigates, clicks, types, and asserts on what the user would actually see.
When to use it (and when not)#
Use E2E for high-value flows and as the final confidence check before release. Do not use it for logic you can test with a fast unit test, or for every edge case. A suite that pushes everything through the browser is slow, flaky, and expensive to maintain.
The challenges#
E2E tests are slow because they run the real app, and brittle because they depend on the UI staying stable. A renamed CSS class or a timing race can turn them red without any real bug. This flakiness is the main reason teams abandon E2E coverage. Keeping it green is the hard part, not writing the first test.
Tools#
The main browser-automation tools are Playwright, Cypress, and Selenium. For how they compare, see Cypress vs Selenium and Playwright vs Selenium. For most new suites, Playwright is the modern default.
Where automation and AI fit#
The maintenance cost is what makes E2E hard to sustain. ObserveOne's Autopilot generates Playwright E2E suites from a URL and self-heals selectors when the app changes, so the journeys keep passing through redesigns instead of breaking on every refactor.
The short version#
End-to-end testing checks a full user journey through the live app, catching the failures that only appear when everything runs together. It is the slowest, most fragile layer, so keep it to your few critical flows, push everything else lower, and lean on tooling to handle the selector maintenance. For the bigger picture, see software testing strategies.