Fixing Design with Tests
summary
Automated tests reveal modularity problems by surfacing concrete pains: long methods, huge setup chains, hidden globals and IO, Law of Demeter chains, flaky sleeps and resource leaks. Tests work as tests as queries (REPL-style immediacy) and as boundaries you can enforce or move; write tests against what runs, let the code tell you its behavior, then apply known fixes like 24 dependency-breaking refactorings, extract classes (eg rule tokenizer) and parameterize external dependencies to make small, testable units.
AI-written summary · about
chapters (9)
- 0:00Introduction
- 2:30Meanings of fixing in testing
- 7:43Testing pains and design problems
- 24:10Testing pain reveals design flaws
- 26:36Tests as design quality indicators
- 31:49Testing boundaries and encapsulation
- 32:31Testing existing code
- 34:17Tests as modularity tests
- 35:01Q&A
related talks
34mBetter Code Through Boring(er) Tests
55mUnit Testing Like a Pro - Towards a Testable Design
41mWhat’s Your Test Design Debt? Avoid the Inevitable!
42mDesign Driven Concepts for Automated Testing
15mTestability: when your testing problem isn’t testing
42mTest-Driven Repair
01h 00mTest-Driven Design Insights - 10 Hints You Were Missing
46mBetter code through boring(er) tests