Research guide
What NOT to Test With E2E Tests
The fastest way to make an E2E suite useless is to test everything with it. This guide covers what belongs in unit, integration, and API tests instead, and the specific things E2E tests should never own.
The test pyramid still applies
Unit tests own logic, integration tests own services, databases, and APIs, and E2E tests own the few critical user journeys. E2E is the most expensive layer, so it should be the smallest.
A suite that tries to test everything end-to-end becomes slow, flaky, and eventually ignored — the opposite of what a quality gate should be.
Don’t test every branch and edge case
Business-logic edge cases belong in unit tests, where they run fast and fail with a precise message. Re-verifying them end-to-end multiplies the cost without adding confidence.
If a unit test already proves the calculation, the E2E test only needs to prove the value reaches the screen.
Don’t test other people’s systems
Third-party UIs, such as Google login, payment iframes, and SMS providers, are not yours to test. Their DOM changes and bot detection fight your suite.
Mock the boundary, assert how your app behaves when the third party succeeds or fails, and let the provider’s own tests cover their UI.
Don’t test the visual layer with E2E assertions
Pixel-perfect layout, spacing, and theme regressions are visual testing problems, not selector-assertion problems. Asserting pixel values inside functional tests makes them brittle for no reason.
Move visual regressions to a visual baseline system, where diffs are reviewed as images instead of failures in the functional suite.
Don’t test implementation details
Component names, CSS classes, internal state, and storage keys are implementation details. If a rename breaks the test, the test was asserting the wrong thing.
Test the behavior a user can observe, and use semantic or test-id hooks only where the user-visible path is genuinely ambiguous.
What E2E should own
E2E owns the critical journeys and release gates: authentication, checkout, the core workflow, and a smoke set after every deploy.
For how to choose those journeys, see the what-to-test guide, and for the visual layer, use the visual-regression guide.
Key takeaways
- Keep E2E for critical user journeys; edge cases live in unit tests.
- Mock third-party boundaries and never test another system’s UI.
- Visual and implementation details belong to their own test layers.