End-to-end (E2E) testing checks whether an application works as a complete, running system rather than only as separate pieces. It provides strong confidence because a scenario exercises the glue between layers, including orchestration with dependencies such as databases and third-party systems. section 10.2.1 section 10.5
That confidence comes with a cost. Compared with unit and component tests, E2E tests are slower, more complex, harder to maintain and debug, and more prone to flakiness. Lower-level tests run quickly and are easier to maintain, but passing them alone does not establish that the application works as one integrated unit. section 10.2.2 section 10.5
An E2E-only strategy is an antipattern. The first broad scenario can validate many paths and connections at once, but later E2E tests often repeat those same dependencies and glue. Their added confidence shrinks while their running, reading, changing, and debugging costs remain high. section 10.2.1 section 10.5
Use E2E tests as part of a balanced test strategy:
- Keep a few E2E tests for the most important functionality, where confidence in the complete running system matters most. section 10.5
- Cover variations at lower levels when a prior E2E test has already established that the main cross-layer glue works. section 10.2.1
- Avoid relying only on unit and component tests, because teams may otherwise need manual testing and debugging before release. section 10.2.2
- Judge the chosen test level by confidence, execution speed, maintainability, complexity, and flakiness. section 10.5
This diagram highlights the risk of a build dominated by high-level E2E tests: broad coverage is offset by slow, flaky, difficult-to-maintain feedback. section 10.2.1
