Claims that TDD is a mindless or tedious activity come only from those without a full understanding of the technique. You can’t succeed with TDD if you don’t think. We want you to not think about the steps in the technique itself–those become habitual after a short while–but instead think about the many things that are involved with growing software incrementally. You’ll need to answer many questions at each step in the TDD cycle.
- Write a small test. What’s the smallest possible piece of behavior you can increment the system by ? Does the system already have that behavior? How can you concisely describe the behavior in a test name?
- Ensure the new test fails. If it doesn’t, why not? Does the behavior already
exist? Should you add this as a new test? Did you forget to compile? Did
you take too large a step in the prior test?
- Write the code you think makes the test pass. Are you writing no more
code than needed to meet the current set of behaviors specified by the
tests? Are you recognizing where the code you just wrote will need to be
cleaned up? Are you following your team’s standards?
- Ensure all the tests pass. If not, did you code things incorrectly, or is your
- Clean up the code changes you just made. What do you need to do in order
to get your code to follow team standards? What do you know about design
and clean code that you should apply here? Does your new code duplicate
other code in the system that you should clean up, too? What other
changes to system design should you make due to the impact of our code
- Ensure the tests all still pass. Do you trust that you have adequate unit
test coverage? Should you run a slower set of tests to have the confidence
to move on? What’s the next test?