TDD via Tic-Tac-Toeby Rob Galanakis on 28/12/2013
- It’s a game. People like programming a game. Learning through games is good. It also reinforces the idea of ‘testability.’ A number of times I had students combine the ‘playing’ of the game with the ‘logic’ of the game. Teaching them to split out the algorithm from the input/driver was a useful exercise.
- It’s not trivial. It is a problem with some real meat that can be solved in a number of different ways. It’s significant enough that a real design and architecture emerges, unlike TDD for a single function. A a bonus, the diverse answers make it fun to teach because I keep being led to new solutions by students.
- The rules are just right. Simple and clear. It has a clear ‘happy path’ and ‘unhappy path’.
- It’s bounded. You can know when it’s good enough, but there are also endless exceptions to check if you want. Which is a great way to teach people to know when something is complete enough.
- It has no dependencies. I prefer not to introduce people to TDD and mocking at the same time.
In the workshops I ran, we did a ‘mob programming’ of a Tic-Tac-Toe game, and then students paired up to develop an AI. While the AI was fun, it was developing the game that was probably a better exercise. And like I mentioned already, I’ve done lots of introductory TDD pairing sessions using it, recently with someone interviewing here which is when I think the Tic-Tac-Toe game really proved itself a successful subject matter. I highly suggest you give Tic-Tac-Toe a try if you’re looking for a way to demonstrate/teach TDD to someone.
If you’re interested, the code and slides I created for the workshops is here: https://github.com/rgalanakis/tddtraining I may make a blog post in the future with some more detail about how the workshops went, if there’s any firstname.lastname@example.org