End-to-end testing verifies an application from the end user’s point of view, reaching directly into all or almost all of its out-of-process dependencies. It is therefore a broad form of integration testing, rather than an isolated check of one unit. section 2.4 section 2.5
Figure 2.6. End-to-end tests normally include all or almost all out-of-process dependencies in the scope. Integration tests check only one or two such dependencies—those that are easier to set up automatically, such as the database or the file system.
Contrast the dependency scope of end-to-end and ordinary integration tests: the former usually includes nearly every external dependency, while the latter limits scope to one or two. section 2.4
Use end-to-end tests deliberately because they make these trade-offs:
- Favor protection against regressions because they exercise behavior close to the user experience. section 4.5
- Provide slow feedback because they include many external dependencies and require more setup and maintenance. section 2.4 section 4.5
- Remain a minority of the suite, with unit tests forming the majority and integration tests occupying the middle layer. section 4.5
- Preserve resistance to refactoring better than unit tests because they remain more detached from production-code implementation details. section 4.5
Database, file system, and payment gateway
Suppose an application depends on a database, the file system, and a payment gateway. An integration test might use the database and file system while replacing the payment gateway with a test double. An end-to-end test includes all three dependencies, exercising the workflow from the user-facing end through the integrated system. section 2.4
