In 30 seconds
- Checks complete user flows, like sign up to purchase.
- Highest confidence, but slowest and most brittle.
- Keep them few and focused on critical paths.
What it covers
End-to-end (E2E) tests drive the system like a user would, through the full stack. They catch problems that only appear when every part works together.
Where it fits
E2E tests sit at the top of the test pyramid: few in number. Most checking should happen in faster unit and integration tests. See automated testing.
Keeping them reliable
- Cover only the most critical user journeys
- Use stable selectors, not fragile page details
- Control test data so runs are repeatable
- Fix or remove flaky tests quickly
Myth vs reality
Myth · More E2E tests means more safety.
Reality · Too many make the suite slow and flaky.
Myth · E2E tests replace manual testing.
Reality · Exploratory testing still finds things scripts miss.
Myth · E2E tests should check every detail.
Reality · Leave details to lower-level tests.
FAQ
How many E2E tests should we have?
Enough to cover critical journeys, often a few dozen.
What tools are common?
Browser automation tools such as Playwright, Cypress or Selenium.
Should E2E tests run on every commit?
A fast critical subset can; the full set can run less often.