TDD as if you meant it – revisited

Yesterday at AltNetUK Openspace Coding Days we repeated the TDD as if you meant it exercise, originally organised by Keith Braithwaite at the Software Craftsmanship 2009 conference. This gave me a chance to once again go back to the problem, but from a completely different perspective.

The exercise involves developing a very simple piece of code strictly adhering to the TDD rules, so much so that participants aren’t allowed to create domain methods or classes other than extracting them from test code. The goal of the exercise is to demonstrate factoring out just what you really need from the test code into domain design rather than starting with a pre-set design structure. Although this is in general taken as a goal of TDD, many programmers (me included) don’t realise how much their assumptions make them jump ahead too quickly. By making it very painful to add new domain code, this exercise slows participants down to a point where people have to spend a considerable amount of time actually focusing code on exactly what is required and no more.

Even on a very simple problem such as tic-tac-toe, differences from a pre-conceived design and the one that emerges from code are considerable, the latter being a lot more elegant and better suited to describe a problem.

The exercise

The original exercise involved stones and the Go game. As I’ve never played that before and we had a lot less time than in the original one, I suggested tic-tac-toe. This turned out to be a very good idea as we spent less time explaining what the domain but it still proved the point of the exercise.

The requirements on the flip-chart were the following:

  • 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 dynamics

All the participants worked in pairs. Most of the teams started by building a 3×3 board and describing requirements that were not given at all (eg first player won, tics or noughts being placed) and took three or four attempts at describing the problem to really go down to basics. As predicted, people were annoyed by this but I did make an effort to explain that the start of the exercise feels silly and annoying so this went much better than I expected. After the first requirement was done correctly, the next three followed easily as they are fairly related. The fifth one though posed a problem again and this is where things got really interesting, some teams falling back on the grid idea (and getting their code deleted) and some teams starting to flesh out the concepts of players and the actual dynamics of fields being taken.

By the end of the exercise, almost half the teams were coding towards something that was not a 3×3 char/int grid. We did not have the time to finish the whole thing, but some interesting solutions in making were:

  • a bag of fields that are literally taken by players – field objects start in the collection belonging to the game and move to collections belonging to players, which simply avoids edge cases such as taking an already taken field and makes checking for game end criteria very easy.
  • fields that have logic whether they are taken or not and by whom
  • game with a current state field that was recalculated as the actions were performed on it and methods that could set this externally to make it easy to test

Most of the game classes had very nice explicit methods for checking different game end criteria. During a short retrospective at the end, some participants said that their code was very nicely isolated and encapsulated, with “less leakage than normal”, and that very explicit specifications ended up in the code making it easy to understand.

Multiple models

This exercise reminded me again about Eric Evans’ introductory presentation to domain modeling. One of the basic ideas there is that the best models are not the most realistic ones but the ones that allow us to describe a particular problem efficiently. The best models are good because they serve a particular purpose in a particular context, so a bag of fields might be a better model of the tic-tac-toe game than a 3×3 board even if the latter feels much more realistic and natural.


In my view, this exercise worked really well. It was interesting to observe it from a different perspective (this time I got the role of the annoying git who went around the room and deleted code that people wrote and did not need). Tic-tac-toe was a good choice as it did not require spending time on explaining and comes with an almost guaranteed 3×3 pre-conceived model. Some participants suggested that we should have done requirements 5 and 6 first and then moved to 1-4. Although this would take away the big refactoring moment, it might actually work better to allow people to factor out a very different model straight from the start. Introducing that the exercise is a bit annoying at the start was also a good idea, as I think that it went smoother than the original one with less opposition to dropping unnecessary code.

You can see some of the code examples on the openspacecode repository. For more information on the original exercise and the rules, see my earlier post about it. Mark Needham repeated the exercise earlier as well, building a message interceptor – something much more technical and practical than a tic-tac-toe or Go game. You can read his conclusions at

I'm Gojko Adzic, author of Impact Mapping and Specification by Example. My latest book is Fifty Quick Ideas to Improve Your Tests. To learn about discounts on my books, conferences and workshops, sign up for Impact or follow me on Twitter. Join me at these conferences and workshops:

Specification by Example Workshops

How to get more value out of user stories

Impact Mapping

13 thoughts on “TDD as if you meant it – revisited

  1. Great writeup, Gojko. I love the idea of the exercise, and it was great hearing how it went from the “other side of the table” this time. Thanks!

  2. I really enjoyed the session. It was an abject lesson in how much we assume and think ahead even when using TDD.

  3. I liked the idea too and it was a good session.

    As you discuss though it might be worth thinking about what requirements are delivered and in what order.

    After finishing 1-4 we had a do nothing style implementation (return trues essentially) that didn’t reflect the real way you play the game (forgetting implementation for a second). I don’t mind ultra simple do nothing solutions, thats a part of TDD. However I normally then write another test that fails because the code under test can’t handle it (for example a test that expects us to return false), and it might be worth rethinking the requirements or their order to allow people to do that (even if it means someone acting as a tic-tac-toe domain expert to answer simple questions).

    Definitely emphasized the fact that we all jump to assumptions though, and was great fun!

  4. I just want to thank you again for leading this session. I’d read your previous article about the exercise at the Software Craftsmanship 2009 conference and was pretty jealous, because it sounded like a great learning experience.

    So I really appreciated you sharing it and being willing to play the role of the “annoying git.”

    I agree that tic-tac-toe was a great domain choice for the 2 hour time slot.

    And I agree with a lot of the comments from your original post about the interesting lessons from it, such as Keith’s:

  5. Interesting how even though the test drives the code, many different solutions were created.

  6. Pingback: Practice, Code Exercises, and Code Katas : Steve Smith's Blog

  7. We’re trying this exercise in our local ( ). And I have some questions, the most important one being : where do encapsulation come from?

    In my result I have no objects with state, and I expose simple types (List of integers) everywhere. It seems unnatural, however if I strictly follow the ‘rules’ well I don’t see how a object Field or Player would spring up.

    Sure the resulting code is very simple. And I do see the benefit of the extremely incremental nature of it. But I’m unhappy about the lack of encapsulation in the result. If someone could have a quick look I’d very much appreciate it.

    I also found that the coding of implementation IN the test has a backside : I can’t code by intent, so I have the impression of tackling all problems at once : what to test and how to write the code. This is to me one of the important benefits of TDD. Anyone felt the same? Will that pass with experience?

    And yet another question while I’m at it : Once I’ve moved a function to the implementation class I can still modify it?

  8. In my experience people often have problems understanding what exactly the rules mean and experienced TDD programmers tend to fake it – in my understanding of “TDD as if you meant it”. Therefore I tried to show how it could be done, so that everybody can see the single steps:

    I am sure it is far from perfect and I would appreciate any feedback (can be given directly for the steps).

  9. Pingback: TDD as if you Meant It « cumulativehypotheses

  10. Pingback: blaulabs » Blog Archive » Get your hands dirty – ein Code Retreat!

  11. I tried this exercise for fun on my own, and I’m really happy with the result. While coding, I made the important observation that rows, columns, and diagonals are really the same thing – just a specification of the layout of the board. So, when I construct the board, I give it a list of what fields are in line (really a set of sets of fields).

    – Since the requirements didn’t specify a 3×3 board, my solution supports any size of board.
    – Since the requirements didn’t specify there are two players, my solution supports any number of players (1 or more).
    – Since the requirements didn’t specify that the board must be two-dimensional, my solution supports 3-dimensional, 4-dimensional, etc. boards. It even supports strange shapes like spherical boards, triangular boards, and whatnot. You just have to specify what fields are in line with each other.
    – My entire solution is around 300 lines. The non-test code is around 100 lines.

    Definitely a fun exercise!

  12. Pingback: Most interesting links of November « The Holy Java

  13. Pingback: On-Site TDD | My Not So Private Tech Life

Leave a Reply

Your email address will not be published. Required fields are marked *