The testing trophy two years later

The original idea

The testing trophy flipped the test pyramid: instead of a broad base of unit tests, it pushed integration tests to the center. The argument was that integration tests give you the most confidence per line of test code. Unit tests are cheap but often test implementation details. E2E tests are expensive and flaky.

What held up

Integration tests as the default has been the single best testing decision I've made. Testing a component with its real hooks, real context providers, and real child components catches bugs that unit tests miss entirely. When you test a form by rendering it, filling fields, and submitting, you're testing what users actually do.

The emphasis on avoiding implementation details also held up. Tests that assert on internal state or mock every dependency break on every refactor. Tests that assert on rendered output and user-visible behavior survive refactors and actually tell you when something is broken.

What I'd adjust

I underinvested in E2E tests for too long. The trophy shows a thin top layer, but for anything with authentication flows, payment processing, or multi-step wizards, a few solid Playwright tests save you from production surprises that no amount of integration tests catch.

I also learned that some unit tests are worth writing. Pure functions with complex logic, like date calculations, currency formatting, or state machines, deserve isolated unit tests. They're fast, stable, and document edge cases better than integration tests can.

The practical balance

My current split is roughly 20% unit, 60% integration, 20% E2E. The numbers aren't the point. What matters is that each test exists because it catches a category of bug that the other layers would miss.