One of the other neat ideas I was reminded of when watching Kent Beck’s TDD screencasts is the value of 'calling your shots' i.e. writing a test and then saying what’s going to happen when you run that test.

It reminds me of an exercise we used to do in tennis training when I was younger.

The coach would feed the ball to you and just before you hit it you had to say exactly where on the court you were going to place it - cross court/down the line and short/deep.

The point of this exercise is that it’s relatively easy to just hit the ball over the net but to have control over exactly where the ball’s going to go is way more powerful albeit more difficult.

This applies to TDD as well - it’s easy to write a failing test but much more useful to write a failing test which fails in exactly the way that we expect it to.

I’ve written previously about the value of commentating when pair programming and calling your shots is a really easy way of keeping the conversation flowing in a pair.

I like to ask not only how a test is going to fail but why it’s going to fail in that way. I think it’s a pretty good way of making sure that you as a pair understand exactly what you’re doing. It also slows the pace just enough that you’re not coding without thinking about what you’re doing.

I quite like Bryan Liles' take on this which he described in a talk at acts_as_conference 2009. Bryan suggests that we first write a test and then either make it green or change the error message that you’re getting.

We should know whether or not the test is going to go green or the error message is going to change before we run the test and the idea is that we want to either get the test to pass in one go or at least get a step closer to a passing test.