Kent wrote the code inside the first test and didn’t pull that out into its own class until the first test case was working. I’ve only used this approach in coding dojos when we followed Keith Braithwaite’s 'TDD as if you meant it' idea. Kent wasn’t as stringent about writing all the code inside the test though - he only did this when he was getting started with the problem. The goal seemed to be to keep the feedback loop as tight as possible and this was approach was the easiest way to achieve that when starting out.

He reminded me of the 'calling the shots' technique when test driving a piece of code. We should predict what’s going to happen when we run the test rather than just blindly running it. Kent pointed out that this is a good way for us to learn something - if the test doesn’t fail/pass the way that we expect it to then we have a gap in our understanding of how the code works. We can then do something about closing that gap.

I was quite surprised that Kent copied and pasted part of an existing test almost every time he created a new one - I thought that was just something that we did because we’re immensely lazy! I’m still unsure about this practice because although Ian Cartwright points out the dangers of doing this it does seem to make for better pairing sessions. The navigator doesn’t have to wait twiddling their thumbs while their pair types out what is probably a fairly similar test to one of the others in the same file. Having said that it could be argued that if your tests are that similar then perhaps there’s a better way to write them. For me the main benefit of not copy/pasting is that it puts us in a mindset where we have to think about the next test that we’re going to write. I got the impression that Kent was doing that anyway so it’s probably not such a big deal.

Kent used the 'present tense' in his test names rather than prefixing each test with 'should'. This is an approach I came across when working with Raph at the end of last year. To use Esko Luontola’s lingo I think the tests follow the specification style as each of them seems to describe a particular behaviour for part of the API. I found it interesting that he includes the method name as part of the test name. For some reason I’ve tried to avoid doing this and often end up with really verbose test names when a more concise name with the method name included would have been way more readable. A couple of examples are 'getRetrievesWhatWasPut' and 'getReturnsNullIfKeyNotFound' which both describe the intent of their test clearly and concisely. The code and tests are available to download from the Prag Prog website.

One thing which I don’t think I quite yet grasp is something Kent pointed out in his summary at the end of the 4th screencast. To paraphrase, he suggested that the order in which we write our tests/code can have quite a big impact on the way that the code evolves. He described the following algorithm to help find the best order: