A search workflow can look correct in the browser yet fail when the UI, API, and connected services interact. End-to-end testing exercises that complete user-facing path across the systems involved. section 2.1.3 section 12.4
E2E tests usually run from a user interface against services deployed to a dedicated environment. They provide high confidence because they resemble real-world use, but they are slower, costlier to develop, harder to maintain, and more difficult to debug than lower-level tests. section 2.1 section 2.1.3
Use E2E testing for the user-visible behavior that other test levels do not fully establish:
- Keep the E2E layer relatively small; place most automation in unit tests, with fewer integration tests and still fewer E2E tests. section 2.1
- Use contract tests for compatibility problems and integration tests for cross-system behavior that does not require the complete user journey; E2E tests remain necessary for full-flow validation. section 2.2
- Replace unstable external calls with mocks inside selected E2E scenarios, then verify the isolated response shape and behavior with a contract test. section 12.4
A browser search scenario
A Cypress test visits GitHub, opens the search control, types “pact,” finds a repository suggestion, and checks its href attribute. The API response can be mocked in the E2E test to improve stability, while a Pact test uses the provider interaction to verify that the response supplies the expected href. section 12.4
Figure 2.4 The original test automation pyramid comprising three horizontal sections: unit tests, integration tests, and E2E tests
The test automation pyramid provides a compact view of how E2E tests sit above unit and integration tests, emphasizing their confidence alongside higher execution cost. section 2.1
