A team is told its test suite should be a pyramid. When is that shape wrong?

When the pyramid is right

When the system's complexity is in its domain logic. A pricing engine, a calculation-heavy service, a rules system — the risk is in the logic, the logic is testable in isolation, and many fast unit tests are the efficient way to cover it.

When it is wrong

When the complexity is in the integration rather than in the units. A service that orchestrates several external providers, transforms data between systems, or coordinates a distributed workflow has thin units and thick seams — and unit-testing the thin units thoroughly tests the part that was never going to break.

For those systems the weight belongs higher: integration tests at the boundaries, contract tests against providers, and a small number of end-to-end tests on critical journeys.

The pyramid shape is a consequence of where the risk is, not a target to aim at.

How to determine the right shape

Review the last twenty production defects and ask which level of test would have caught each. That produces a better strategy than any general principle, and it takes an afternoon.

A suite that tests the easy parts thoroughly and the dangerous parts not at all is the common outcome of applying a standard shape regardless of where the risk lives — and the review makes it visible immediately.

The properties that matter more than the shape

• Speed, because a suite that is too slow to run before merge provides feedback too late to be actionable.
• Determinism, because flaky tests are worse than no tests — they train the team to re-run and therefore to ignore real failures.
• Diagnosability, since a failure that takes an hour to attribute will be re-run rather than investigated.
• Testing behaviour rather than implementation, so the suite fails on regressions and not on refactoring.

The financial-domain addition

Correctness tests for the money paths must be exhaustive at the unit level regardless of the shape: rounding, currency, partial amounts, reversals, and every state transition in the ledger.

That is the one area where thoroughness at the lowest level is non-negotiable, because the failures are silent — the arithmetic works and the number is wrong.