2.3The Testing Trophy (Kent C. Dodds, 2018)

            /  E2E  \
           /─────────\
          / Integration \        ← Most tests here
         /    Tests      \
        /─────────────────\
       /   Unit    /  Static \
      /───────────/───────────\

The Principle

The trophy inverts the emphasis for frontend-heavy applications:

• Static analysis (TypeScript, ESLint) catches the cheapest bugs at zero runtime cost
• Unit tests for pure logic and utilities
• Integration tests are the sweet spot -- they test components as users interact with them, hitting the best confidence-to-cost ratio
• Few E2E tests for critical paths only

Why Dodds Proposed It

In frontend applications, unit testing individual React components in isolation (mocking all dependencies) gives low confidence because the real risk is in how components interact. An integration test that renders a form, fills in fields, and submits it tests the actual user experience far better than 50 isolated component unit tests.

When the Testing Trophy Works Best

• Frontend-heavy applications (React, Vue, Angular SPAs)
• Applications with simple business logic but complex UI interactions
• Teams using component libraries where individual components are already tested upstream
• Projects where TypeScript or static analysis catches many potential bugs