Chapter 1 · Practice 1 of 4
Shape the suite like a pyramid: many unit tests, fewer integration tests, very few end-to-end tests
Why it matters
The test pyramid groups tests by how much of the system they exercise. As Martin Fowler's article on the practical test pyramid puts it, the more high level you get, the fewer tests you should have.
| Level | What it exercises | Speed | How many |
|---|---|---|---|
| Unit | One function, class or module | Milliseconds | Many |
| Integration | Your code plus one real dependency, such as a database or HTTP client | Seconds | Some |
| End-to-end | The whole deployed app through its UI or public API | Seconds to minutes | A few critical journeys |
The opposite shape, sometimes called the ice cream cone, has most of its tests at the top. Those suites are slow, break for reasons unrelated to the change, and make it hard to tell which part of the system is wrong.
The exact names matter less than the principle: write lots of small, fast tests and a few broad, slow ones. Teams argue about what "unit" means. Agree on a definition inside your team and move on.
Do
- Count your tests per level once a quarter and see which way the shape is drifting
- Treat each end-to-end test as expensive and keep only the ones that protect a key journey
Avoid
- Covering every edge case through the UI when a unit test could check it in milliseconds