We coded in Java in eclipse which I haven’t used for about a year and I was really surprised at how rapid the feedback cycle was. We seemed to be able to write a test and have it failing within seconds which is brilliant and just the way it should be whereas I’ve got used to a much slower feedback loop when using Visual Studio.

We noticed as we did the previous times when we did this exercise that you notice objects in the code that you wouldn’t normally have noticed if we hadn’t been writing all the implementation details in the test first. The 'Square' object was one which neither I nor Dave had expected to exist. We had imagined that code would end up on the 'Game' object and interestingly just before our colleague joined us we had drifted from the rules of the exercise and actually written the outline of a method on the game object to satisfy the 5th acceptance criteria 'a player can take a field if not already taken'. Luckily we undid that and it became obvious that the new code should be on an object of its own so that’s what we did.

The code we have at the moment has everything implemented just using booleans which felt really weird when we were writing the code but seemed to be the simplest thing to do to meet the acceptance criteria. We discussed this at the time and it seemed that any alternative approach where we didn’t do this would end up with us writing a really big test (perhaps with players making moves), therefore meaning the feedback cycle would be really slow.

I think it would probably be quite interesting to try out this type of exercise and commit to either Git or Mercurial after each of the small steps so that we could see the story of the code more clearly afterwards.

During our discussion on Continuous Integration a few weeks ago it was suggested that we could some sessions on parallelising tests and writing impersonators during one of our coding dojos so we might look at doing that next time around.