Testing Diamond: Unit, Integration, and E2E Test Balance

The testing pyramid says write mostly unit tests, but modern apps with microservices and APIs get more value from integration tests. Teams argue about the right balance.

The testing trophy/diamond model for modern apps:

     /\        E2E tests (few, critical paths)
    /  \       - Login flow, checkout, signup
   /    \      - 5-10 tests covering happy paths
  /------\     
 /        \    Integration tests (most value)
/          \   - API endpoints with real DB
\          /   - Component + service interactions
 \--------/    - Module boundaries
  \      /     
   \    /      Unit tests (pure logic)
    \  /       - Algorithms, calculations
     \/        - State machines, validators

Guidelines:

1. Unit tests for pure functions with complex logic

- No mocking needed = good unit test candidate
- Math, parsing, validation rules, state machines

1. Integration tests for behavior at boundaries

- HTTP handlers with real DB (use test containers)
- Service layer with real dependencies
- React components with real state management

1. E2E tests for critical user journeys only

- Sign up -> login -> core action -> verify
- Payment flow, onboarding, key workflows
- Max 5-15 E2E tests for most apps

1. Static analysis as the base

- TypeScript, ESLint, mypy catch entire categories of bugs
- Cheaper than any test to maintain

Over-investing in unit tests that mock everything gives false confidence. Integration tests catch the bugs users actually hit: misconfigured routes, wrong SQL, broken serialization.

Deciding test strategy for a project