Coding Dojo #21: TDD as if you meant it revisited
In this weeks dojo we decided to revisit the “TDD as if you meant it’ exercise originally invented by Keith Braithwaite for the Software Craftsmanship Conference but recently tried out at the Alt.NET UK Conference in London.
The idea was to write code for ‘tic tac toe’ or ‘naughts and crosses’ and we were following these requirements:
- a game is over when all fields are taken
- a game is over when all fields in a column are taken by a player
- a game is over when all fields in a row are taken by a player
- a game is over when all fields in a diagonal are taken by a player
- a player can take a field if not already taken
- players take turns taking fields until the game is over
The code from Alt.NET UK is available on Google Code and what I found quite interesting is that the solutions are really quite different to each other.
Our code is up on bitbucket and again it is quite different to the other approaches.
For most of this week’s dojo Dave and I just worked together on the problem although a colleague did come and join us for the last half an hour or so. We were just pairing on a Mac.
What We Learnt
- 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.
For next time
- 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.