Test strategy and the test pyramid
How many tests of each kind to write, where the expensive ones earn their keep, and how to argue about it with evidence.
Almost every argument about test strategy is really an argument about proportion. Nobody thinks end-to-end tests are worthless; nobody thinks unit tests are sufficient. The question is always the mix, and the two best-known answers disagree with each other in a way that is genuinely useful.
The pyramid's argument is about cost. A test that drives a browser is slower to run, slower to write, and fails for more reasons than the one you care about, so you want as few of them as will do the job. The trophy's argument is about confidence: a unit test that mocks everything its subject talks to proves the subject works against your beliefs about its collaborators, which is not the same as working. Both are right, and which one describes your application depends on where its bugs actually come from.
| Layer | Answers the question | Fails when |
|---|---|---|
| Unit | Does this function do what I meant? | The logic is wrong |
| Integration | Do these parts agree with each other? | An interface changed, or an assumption was wrong |
| End-to-end | Can a person actually complete this? | Anything at all, which is the cost and the point |
The practical rule that survives both models: write the test at the lowest level that can still fail for the reason you care about. If a bug would have been caught by a unit test, a browser test that catches it is an expensive way of being right. If a bug can only appear when four services and a browser are in the room together — and the ones that reach customers usually can — no amount of unit testing will find it.
“70/20/10” is a description of a suite that already works, not an instruction for building one. Teams that adopt the numbers without the reasoning end up writing shallow unit tests to move a percentage, which costs real money and buys nothing. Decide per feature; measure by escaped defects, not by shape.
The two models, in their authors' words
4 entriesRead both. They are short, and the disagreement is the valuable part.
-
Ham Vocke's long essay on martinfowler.com, and the clearest available explanation of why a suite that is mostly end-to-end tests becomes slow, brittle and expensive. It also does the thing most pyramid articles skip: it shows real code at each layer.
martinfowler.com -
The Testing Trophy
EssayKent C. Dodds's reply, arguing that integration tests give the most confidence per unit of effort and that the pyramid over-weights the bottom. Written from a front-end perspective, which is where the argument bites hardest.
kentcdodds.com -
Google's own post on the subject, and unusually candid about the failure mode: an end-to-end suite that takes hours, fails for unrelated reasons, and is eventually ignored by the people it was built to protect.
testing.googleblog.com -
Test Sizes
EssayThe other half of Google's model, and the more practical half. Instead of arguing about what to call a test, classify it by what it is allowed to touch — the filesystem, the network, another process — and let the runtime budget follow from that. This survives contact with a real codebase better than the pyramid does.
testing.googleblog.com
Making the tests you keep worth keeping
3 entries-
xUnit Test Patterns
EssayGerard Meszaros's catalogue of test smells and the patterns that fix them. Old, dense, and still the reference for why a particular test is hard to read or impossible to change. The site is free; the book is the same material with editing.
xunitpatterns.com -
Martin Fowler on what to do when a suite stops being trusted. The key move is treating a non-deterministic test as a broken test and quarantining it immediately, rather than letting the whole suite's credibility drain away to protect one test's feelings.
martinfowler.com -
Playwright: test projects
Official docsStrategy eventually becomes configuration. Projects are how one Playwright suite runs the smoke subset on every push and the full matrix nightly, with setup dependencies between them, without a second repository.
playwright.dev
What to take away
- Write the test at the lowest level that can still fail for the right reason.That single rule resolves most pyramid-versus-trophy arguments in practice.
- Classify by what a test touches, not by what you call it.Google's test sizes travel better than layer names, which every team defines differently.
- Quarantine a non-deterministic test the day you find it.One test that fails randomly costs the whole suite its authority.
Reading is the slow way to learn how a suite behaves. Record one against your own app, free, and watch what the report says.