What Tests Actually Buy You

The test pyramid isn't a shape — it's a cost model. Unit tests are cheap to write and cheap to run; integration tests cost more and catch different bugs; e2e tests are the most expensive and the most fragile. The pyramid inverts the cost curve so your confidence-per-dollar stays high.

What tests are really for

1. Regression safety — a test that fails when you break something is worth the code it protects. This is the core job.
2. Design pressure — code that's hard to test is usually coupled or has hidden dependencies. The test is a design review you didn't have to ask for.
3. Documentation that can't lie — a test describes what the code does, not what you hoped it would do.

What tests are not: proof of correctness, a substitute for thinking, or a target metric. 90% coverage of trivia while the money path is untested is worse than 50% that covers the money path — the number tells you nothing about which paths are covered.

The pyramid, quantified

        /  e2e  \        — few, slow (seconds-to-minutes), highest confidence per test
       /integration\     — medium count, medium speed, catches interface bugs
      /    unit     \    — many, fast (<10ms each), catches logic bugs

A suite that looks like an ice cream cone (mostly e2e, thin unit) spends CI minutes catching what a unit test catches in milliseconds — and it's fragile, so engineers learn to ignore failures, which is worse than no tests.

The tests nobody writes

• The bug that just shipped — write the test that reproduces it before writing the fix.
• The invariant — "balance never goes negative" is a test even when the code is obvious.
• The boundary — empty list, max int, unicode, timeout — the places code breaks in production.

Field notes

• A flaky test is worse than no test — it trains the team to ignore red builds. Quarantine it, fix it, or delete it.
• Test behavior, not implementation. A test that mocks every dependency is testing your mock wiring, not your code.