The pyramid, the trophy, and choosing per system

The test pyramid is a model for how many tests to write at each level. A wide base of unit tests, fewer integration tests, and a thin top of end-to-end tests. The logic is cost: lower tests are faster, cheaper and more precise about what broke.

The testing trophy is a later model with a different shape. A small base of static checks and unit tests, a fat middle of integration tests, and a thin top of end-to-end. Its logic is confidence: most real defects live in how the pieces connect, so test there.

Neither is a rule. Both are arguments about where your defects actually are, and the honest answer differs per system.

The useful question is not which model is correct. It is what shape your own failures suggest.

The terms you will hear

• Unit test. One function or class, dependencies replaced. Milliseconds.
• Integration test. Several parts together, often with a real database. Seconds.
• End-to-end test. The whole system through its interface, as a user. Tens of seconds.
• Static checks. Types, linting, schema validation. No execution required.
• Contract test. Two services agreeing on a shape without running both.
• Ice cream cone. The anti-pattern. Mostly slow end-to-end tests, few unit tests.

What each level buys you

• Unit tests tell you precisely what broke, run in milliseconds, and can pass while the product is entirely broken. They know nothing about wiring.
• Integration tests catch the wiring, which is where a surprising share of real defects live. They cost seconds and are harder to diagnose.
• End-to-end tests are the only ones that prove a user can actually do the thing. They are slow, they break for environmental reasons, and a handful of them is worth more than a hundred.

Why it matters

Because the shape decides how long your suite takes, and suite duration decides whether it gets run.

For example, a team with 40 end-to-end tests and 60 unit tests has a suite taking 25 minutes and failing twice a week for reasons unrelated to the product. The same coverage rebalanced towards integration runs in four minutes and fails when something is genuinely wrong. Same confidence, entirely different relationship with the team.

How to choose your shape

1. Start from escaped defects, not from a diagram. Twenty of them, categorised by the level that would have caught each.
2. Add the shape of your system. Heavy business rules in one service argue for unit tests. Thin services calling other services argue for integration and contract tests.
3. Count the cost you already pay. Suite duration, flake rate, and time spent diagnosing failures. Your run history has all three, and a high diagnosis cost means your tests sit too high.
4. Set a target shape and a budget. For example, ten minutes total. Then every new test has to earn its place, which is the pack discipline from choosing what stays.
5. Keep end-to-end tests few and precious. The critical journeys only. Payment, login, the one thing your business does.
6. Write the decision down. It belongs in the test strategy, because it is exactly the kind of argument a strategy exists to settle once.

A worked decision

For example, here is one small team choosing, with the evidence.

The team ended up closer to a trophy, and not because they preferred the model. Eight of fourteen escapes pointed at one level, and the shape followed the evidence.

How to show you know it

• A defect-to-level table. Twenty escapes categorised. It is the most persuasive artefact in this topic.
• A suite time budget. "Ten minutes, so a new test displaces an old one."
• A justified end-to-end list. Nine named journeys beats thirty-eight accumulated ones.
• A shape written into the strategy. It stops the argument recurring every time somebody adds a test.