2.2The Classic Test Pyramid (Mike Cohn, 2009)

            /  E2E  \            Few, slow, expensive
           /  Tests  \
          /───────────\
         / Integration \         Some, moderate speed
        /    Tests      \
       /─────────────────\
      /    Unit Tests     \      Many, fast, cheap
     /─────────────────────\

The Principle

• Many unit tests at the base: fast, cheap, isolated, run on every commit
• Fewer integration tests in the middle: verify component interactions, moderate speed
• Few end-to-end tests at the top: slow, expensive, brittle, but verify the full user journey

Why It Still Matters

The pyramid encodes a cost-benefit truth that has not changed since 2009:

Test Type	Execution Speed	Maintenance Cost	Failure Specificity	Confidence Level
Unit	Milliseconds	Low	High (pinpoints the problem)	Low (doesn't test integration)
Integration	Seconds	Medium	Medium	Medium
E2E	Minutes	High	Low (fails, but where?)	High (tests real user path)

The pyramid says: invest most in the test type that gives you the best ratio of cost to feedback speed. Unit tests win that ratio by a wide margin.

When the Classic Pyramid Works Best

• Backend services with complex business logic (calculation engines, data processing)
• Libraries and frameworks where API contracts matter more than UI
• Microservices where each service has clear boundaries and contracts
• Mature codebases with high unit test discipline