Mechanically, the TDD cycle is:
- Write enough test to get a failing test
- Write enough code to get the test passing
- Refactor the code to make sure it’s following good design principles
You could spend a lot of time on each of those as well as making sure that the code you write is testable and changeable.
Whenever you’re doing any one of these three steps, you’ll have to run the tests.
Before you run them, stop and think. Predict what the outcome of the test will be.
You want to know what the test is going to do, and a failure that you expect is better than a passing test that you don’t understand. Your goal is to be in control of your system.
Seriously, don’t farm the thinking out to the computer and shut off your brain. You need the mental model of how your system works, and the best way I’ve seen to get there is to predict your test outcomes before you run them.
If you’re not writing tests, well… that’s a subject for another email.
