TDD: The Good Parts

Test-driven development can be hard, and a lot of the “rules” can often become a distraction from the real reasons you're writing tests in the first place.

In this talk, you’ll find out what the real benefits of TDD are, what really makes code “good”, and why testability shouldn’t be your only yardstick for measuring code quality.

I’ll also show you some of the pitfalls of a “purist” testing approach, and give you strategies you can use to test-first without sacrificing simplicity or expressiveness in your code.

If you’ve ever given up on testing because it seemed so hard to do everything “by the book”, this talk will feel like a breath of fresh air and give you the tools you need to start writing tests that really matter.

Transcript

1. TDD The Good Parts @adamwathan
8. Code that's hard to test in isolation is poorly designed 1 Test Driven Evangelists
9. Isolated testing has given birth to some truly horrendous monstrosities of architecture. 1 David Heinemeier Hansson
10. A dense jungle of service objects, command patterns, and worse. 1 David Heinemeier Hansson
11. What makes good code?
12. 1. Easy to change
13. 2. Easy to understand
15. 3. Enjoyable to use
19. What am I doing wrong?!
20. Why test first?
21. 1. Confident refactoring
22. 2. Emphasize public API
23. 3. Identify task at hand
24. Isolation is overrated
25. Pitfall #1 Lying tests
54. Solution #1 Use real collaborators
62. When your tests use the same collaborators as your application, they always break when they should. 1 Sandi Metz
63. The value of this cannot be underestimated. 1 Sandi Metz
64. Pitfall #2 Implementation coupling
80. Solution #2 ... Use real collaborators!
89. The great irony of over- isolation is that it actually makes you more dependent on implementation. 1 Steve Fenton
90. Pitfall #3 The Dreaded "Design Damage"
92. Easy to understand?
93. Enjoyable to use?
94. Easy to unit test?
96. This tests nothing.
137. Solution #3 FOR THE LOVE OF GOD USE REAL COLLABORATORS!!!!
146. If talking to the database is stable and fast then there's no reason not to do it in your unit tests. 1 Martin Fowler
147. Testing is an art
148. ...and a Journey
149. Push yourself to learn