Feedback arrives after the context is gone
A forty-minute journey fails for a one-line change. The author is already on the next task.
A pyramid is a budget.
The picture is famous. The decision is not. Most checks should be cheap. A few should prove a journey. The middle protects the contracts.
- Many fast checks
- Contracts in the middle
- Few journeys at the top
Read it from the base.
Wider means more checks, not more importance. A thin top is a choice.
JourneysFew end-to-end paths. Slow, brittle, and reserved for flows that cross the product.
Contracts and integrationThe promises between services, with data you control.
Unit and componentThe bulk of the suite. Specific, fast, and close to the change.
Why teams invert it.
An end-to-end-heavy suite feels safer and then becomes the reason nobody trusts the build.
Failures are ambiguous
A red journey can be a product defect, a fixture, a clock, or another team. The suite stops teaching.
Reruns replace root cause
If the second run is the process, the first run was never a signal.
When the pyramid should bend.
Risk can justify a heavier top. The reason belongs in the strategy, not in a slogan.
Regulatory or money movement
A journey that moves funds or files a legal record may deserve more end-to-end proof than a settings screen.
A thin system
A small product with one process may not need a large unit layer on day one. It still needs the journey to be few, not infinite.
A migration
Characterisation tests around a legacy boundary can be awkwardly shaped. They should expire when the boundary is understood.
If the top is doing all the work, say so.
We can look at where the suite is spending time and which layer should own the next risk.