Personal notes on Michael Feather's talk about testability and good design.
The Deep Synergy Between Testability and Good Design (http://vimeo.com/15007792)
- Making code design better, makes testing easier.
- But making code easier to test, does not necessary make code design better.
- codebase is maintained by human.
- hard-to-understand code
- need more time to make changes (longer delivery time, lower predictability)
- higher chance to make mistakes when making changes (lower quality)
- good code design = easier-to-understand code, easier to make changes
- writing automated tests makes you feel the concrete pain of poor code design.
- because hard-to-understand code = hard to write automated tests to check against the code
| Pain | Poor code design (what to fix) |
|---|---|
| 1. Wish to access local var in tests | SRP violation |
| 2. difficult setup | too much coupling |
| 3. incomplete resource cleanup | poor encapsulation |
| 4. state leaks across tests | global mutatble state |
| 5. framework frustration | not enough separation between framework & domain |
| 6. difficult mocking | law of demeter violation |
| 7. difficult mocking concrete class | lack of interface/abstract class, dependency inversion principle violation |
| 8. hidden side effects | encapsulation violation |
| 9. hidden inputs | over encapsulation |
| 10. long input param list | too many responsibilities, SRP violation |
| 11. wish to test private method | SRP violation |
| 12. many tests need change when code change | open/closed principle violation |