The Test Pyramid: Unit, Integration, End-to-End
Not all tests are the same. They come in layers, from tiny checks on one piece of code to full run-throughs of the whole app. The test pyramid is the standard guide to how a healthy test suite should be balanced across those layers: many small fast tests at the base, fewer big slow ones at the top.
There are three main layers — unit, integration, and end-to-end — and the pyramid shape tells you roughly how many of each to have.
A good analogy is inspecting a car. You check each part on the bench (unit), then test assembled systems like the brakes and electrics together (integration), then take the whole car for a test drive (end-to-end). You do lots of the cheap bench checks and only a few full test drives.
| Layer | Checks | How many |
|---|---|---|
| Unit | One small piece in isolation | Many — fast and cheap |
| Integration | Several pieces working together | Fewer — moderate cost |
| End-to-end | The whole app, like a user | A handful — slow and fragile |
Unit Tests
Unit tests check one small piece of code — a single function or component — in isolation from everything else. They're fast (thousands run in seconds), cheap to write, and pinpoint exactly what broke when they fail. Because they're so cheap and precise, you have lots of them; they form the wide base of the pyramid and the backbone of a test suite.
Integration Tests
Integration tests check that several pieces work correctly together — for example, that the code and the database cooperate, or that two modules hand off properly. They catch problems unit tests can't see, because a part can work alone yet fail when connected. They're slower and a bit more involved than unit tests, so you have fewer of them — the middle of the pyramid.
End-to-End Tests
End-to-end (E2E) tests exercise the whole application the way a real user would — open the app, click through a flow, check the result. They give the most realistic confidence, but they're slow, complex, and fragile (a tiny interface change can break them). So you keep only a handful, covering the most important journeys. They sit at the narrow top of the pyramid.
Why a Pyramid, Not an Ice-Cream Cone
The shape is the lesson. A healthy suite is a pyramid — broad and fast at the bottom, narrow and slow at the top. The classic mistake is the inverted "ice-cream cone": lots of slow, brittle end-to-end tests and few unit tests. That suite is slow to run, painful to maintain, and flaky — so the team stops trusting it. Keeping the pyramid right-side up is what keeps testing fast and reliable.
Cadence's suite has the right shape. There are hundreds of fast unit tests on the streak math, a dozen integration tests checking that saving a check-in really lands in the database, and just three end-to-end tests that mimic a user creating a habit and seeing a reminder fire. Lots of cheap checks, a few expensive ones — a textbook pyramid, and a suite the team actually trusts.
- "End-to-end tests are the most valuable, so write mostly those." They're slow and fragile, so you keep them few. Relying mostly on them is the inverted-pyramid anti-pattern that makes suites painful.
- "Unit tests are too trivial to bother with." They're the fast, precise backbone of the suite — the wide base that makes testing cheap and quick to run on every change.
- "The pyramid is a strict rule about exact numbers." It's a proportion guide, not a precise law — lots of unit tests, fewer integration, a few end-to-end. The shape matters, not exact counts.
- The pyramid tells a team where to invest testing effort — lots of cheap unit tests, a few expensive end-to-end ones — for a fast, trustworthy suite.
- Recognizing the inverted "ice-cream cone" as a real, costly mistake helps you spot an unhealthy suite before it slows the whole team down.
- "Unit", "integration", and "end-to-end" are everyday testing words — knowing what each covers lets you follow any testing conversation.
Knowledge Check
What does a unit test check?
- One small piece of code, like a single function, in isolation
- The whole application working together, just as a user would use it
- Several pieces of the system working correctly together at once
- How quickly the finished program runs for its end users
What do integration tests catch that unit tests can't?
- Problems where parts work alone but fail when connected together
- How fast the entire finished program runs under heavy load
- Bugs inside a single isolated function, tested entirely on its own
- What real users think and feel about the finished product
Why do teams keep only a handful of end-to-end tests?
- They're slow, complex, and fragile, so only the key journeys are covered
- Because end-to-end tests provide no useful confidence at all
- Because each single end-to-end test costs a very large amount of money to run
- Because they only ever check how the screens look visually
What is the "ice-cream cone" anti-pattern?
- An inverted pyramid — many slow end-to-end tests and few unit tests
- A healthy suite with many unit tests and few end-to-end tests
- A project that has decided to write no automated tests of any kind whatsoever
- A suite made up entirely of tests that all run extremely fast
What does the pyramid shape actually tell a team?
- Roughly how many of each kind of test to have, as a proportion
- The exact number of tests every project must write by law
- The exact order in which the tests should run during a build
- Which specific testing tools and frameworks the team must adopt
You got correct