The testing pyramid recommends a relative distribution of unit, integration, and end-to-end tests. Unit tests form the majority, integration tests occupy the middle, and end-to-end tests remain the minority. Lower layers favor fast feedback; higher layers favor protection against regressions. The exact ratio depends on project complexity, but every layer should resist refactoring and minimize false positives. section 4.5 section 4.6
Use the pyramid as a cost-and-coverage guideline:
- Check as many business-scenario edge cases as possible with fast, inexpensive unit tests. section 8.1
- Use integration tests for one happy path per business scenario and for edge cases that unit tests cannot cover. section 8.1
- Keep integration tests fewer because out-of-process dependencies make them slower and more expensive to maintain, despite stronger system-level regression protection. section 8.8
- Adjust the shape for complexity: simple projects may need equal numbers of unit and integration tests, or no unit tests in trivial cases. section 8.8
A business scenario
For a scenario such as changing an email address, test the domain model's edge cases with unit tests, then use an integration test to exercise the controller and the system's successful path. Keep communications with unmanaged dependencies mocked, while using real managed dependencies where required by the integration boundary. section 8.1 section 8.8
Figure 4.12. Different types of tests in the pyramid make different choices between fast feedback and protection against regressions. End-to-end tests favor protection against regressions, unit tests emphasize fast feedback, and integration tests lie in the middle.
Compare how unit, integration, and end-to-end tests trade execution speed against regression protection. section 4.5
