5 Testing as waste prevention
This chapter covers
- Distinguishing tests that prevent rework from tests that create it
- Writing tests before implementation to catch defects when they're cheapest to fix
- Structuring test layers around actual risk instead of theoretical coverage
- Treating flaky tests as the flow-blocking defects they are
- Deciding what not to automate when AI offers to generate tests for everything
- Using coverage to expose risk rather than inflate confidence
Have you experienced any of these?
Your CI pipeline fails. Random timeout. You hit rerun. It passes. You merge. Three days later, production breaks in the same area because the flaky test masked the real defect.
You inherit a test suite with 2,400 tests and 18-minute CI runs. No one's entirely sure what half of them do. When you refactor a service to use a different database client, 47 tests break, even though user behavior stays identical. You spend three hours updating mocks that were never protecting value in the first place.
AI generates 34 test cases for your business logic. It looks thorough; every conceivable edge case is present, and null checks and exception paths are covered as well. Six months later, you make a small change to shift a calculation from a lookup table to a database query. All 34 tests go red. The actual business behavior still works, but the tests were asserting internal structure, not business outcomes. This cost two hours of rework for changes that added zero risk.