TDD Revisited
summary
Claims that TDD means writing isolated “unit” tests, that each new test maps to a new function, that customers write SpecFlow acceptance tests, that test‑after equals test‑first, or that TDD guarantees 100% coverage are false. The talk shows how overusing mocks produces mock-driven fragility, explains TDD as exploring APIs by driving developer tests from user behavior triggers, recommends ports‑and‑adapters to isolate IO, and prescribes only writing production code in response to a failing behavior test to avoid speculative or rigid design.
AI-written summary · about
chapters (11)
- 0:00Introduction to TDD
- 2:00The fallacy of unit tests
- 7:01Refactoring and testing
- 13:25The role of developer tests
- 16:26TDD as behavior discovery
- 21:00Requirements and scope
- 22:35Acceptance test realities
- 26:09Testing order and strategy
- 29:22Limits of test coverage
- 33:08Testing pyramid and summary
- 37:05Final conclusions
