If you're at all familiar with Test-Driven Development, you've probably heard "Red, Green, Refactor" as the three stages of the process. This translates to the steps: write a (single) failing test, write code to make it pass, and refactor. You may have also heard claims that "TDD improves your design", or "TDD reduces bugs [to zero]", or "TDD means all code is tested", however, TDD does none of these things unless you know what to pay attention to and know how to refactor towards better design.
If you watch an experienced practitioner do TDD, you will see a lot more activity between the three steps, not to mention the thought behind the work that you can't see.
In this talk, we'll explore what to look for during those three seemingly simple steps, and learn heuristics that you can apply throughout the TDD process.
- Is this test easy to write? If not, why? How can I fix that? This may involve refactoring the production code, or the test code.
- When I see this test fail, do I understand why it failed? Did it fail as expected? Will I still understand it if it fails in 3 months?
- What does Kent Beck's saying "Make the change easy (this may be hard), then make the easy change" actually mean?
- Why does taking Many More, Much Smaller (and Safer) Steps (MS^3, adapted from GeePaw Hill) make me go faster, and why is it so hard?