What lower-level tests cannot catch
Unit tests confirm that your functions return the right values. Integration tests confirm that your services can communicate. Neither confirms that a real user, in a real browser, can complete a real task.
The gap matters most on the flows where failure is immediately visible and expensive: authentication, checkout, onboarding, billing changes, support requests, and any admin action that touches live data. A unit test suite going green while your checkout button is broken is a failure of test strategy, not a test failure.
End-to-end tests close that gap. They are not a replacement for unit or integration tests — they are the layer that proves the assembled product actually works.
- Navigation and routing issues that only appear in the assembled browser environment
- Broken selectors, disabled buttons, or missing form state after a deploy
- Backend/API mismatches that pass unit tests but fail the real user journey
- Regressions in revenue-critical or support-critical workflows
- Third-party integration failures that only appear at the UI boundary
Why teams still avoid it — and why that reasoning is wrong
Most teams do not skip E2E testing because they disagree with the principle. They skip it because their last attempt was painful. Tests broke constantly. Nobody understood why they were failing. Updating them after a UI change took longer than the change itself.
That is a problem with the authoring and maintenance model, not with E2E testing as an idea. Suites that encode every DOM detail at the lowest possible level will break constantly. Suites that encode user intent at a readable, reviewable level hold up significantly better.
The teams that successfully maintain E2E coverage are usually the ones who made a deliberate choice about what level of abstraction to write at — and who kept the resulting artifacts in their repository so they could be reviewed, versioned, and updated like any other part of the codebase.
The flows worth covering first
Not every flow needs E2E coverage immediately. The right starting point is the flows where breakage is immediately user-visible and where your unit tests would not catch it.
Authentication is the obvious first target. If login breaks, nothing else matters. Checkout is next if your product takes payments — revenue stops the moment that flow regresses. Onboarding, account updates, billing changes, and support request submission are all strong candidates for the same reason: they are high-consequence, cross-boundary flows that only a browser-level test can fully validate.
- Login and authentication — the entry point to everything
- Signup and onboarding — first impressions and conversion
- Checkout and payment flows — direct revenue impact
- Account settings and billing changes — high-trust, high-risk
- Support request submission — failure here goes unnoticed until customers complain
A maintainable strategy from the start
The single biggest investment you can make in E2E testing sustainability is choosing where the human-readable definition lives. If the primary artifact engineers review is raw browser automation code, maintenance will always be expensive. If the primary artifact is a readable scenario that describes what the user is doing and what they expect to see, updates become much more manageable.
Assert is built around this principle. Scenarios are defined in plain-English Markdown, kept in the repo, and used to generate the Playwright execution layer. When the UI changes, engineers update the scenario — not hundreds of lines of selector code. That distinction compounds over time.
URL: https://app.example.com/login SCENARIO: User can log in and reach dashboard PROCESS: - Fill "email" with "qa@example.com" - Fill "password" with "hunter2" - Click "Sign in" EXPECT: Dashboard
FAQ
When should a team add end-to-end tests?
As soon as the product has one or two user-critical flows that would be painful or expensive to break. Login is almost always the right first target. If your product takes payments, checkout should follow immediately. You do not need comprehensive coverage from day one — you need coverage of the flows that would cause an incident if they broke silently.
Do E2E tests replace unit tests?
No, and they should not try to. Unit tests are efficient at validating logic in isolation. E2E tests are the only layer that validates the assembled product in a real browser against real behavior. A mature test strategy uses both: unit tests to keep logic correct, E2E tests to keep user journeys intact.
Why do teams get burned by E2E testing?
Almost always because they wrote tests at too low a level — targeting unstable DOM selectors, encoding UI layout details, and building suites that break every time a component moves. The fix is not to abandon E2E testing; it is to write at the level of user intent rather than DOM mechanics. Readable, repo-native scenarios that can be regenerated when the UI shifts are far more durable than hand-authored browser scripts.
Put the workflow in your repo, not in a chat transcript
Assert is strongest when scenarios become durable project assets: readable Markdown in the repo, generated execution underneath, and result inspection in the dashboard.