To test, or not to Test? Part 1 – Why Test? And at what cost?

A reflection on 35 years of coding experience examining when tests are valuable and when they aren't. Covers three core reasons to test (checking expectations, preventing regressions, driving implementation), common sources of defects (nulls, shared mutable state, integration problems, programming traps), and the real costs of maintaining automated tests. Identifies scenarios that are inherently hard to test—combinatorics, multi-threading, stateful code—and hints at future posts exploring cheaper alternatives to some tests. Argues that quality standards should be context-dependent rather than aiming for 100% coverage.