Usually when I’m wrapping up my 3 day TDD Workshop, I make it clear to the participants that they will have to deliberately practice, every single day, for a few years, to get better at TDD. In addition to practicing on their own, on pet projects and on production code, I also suggest they take 2 hrs every week on a fixed day of the week, as a whole team, to practice Test-Driving (TDD) the same problem as a team. During these sessions, I strongly recommend people practice Pair programming also.
Logistics: Before the meeting, one of the team member sends out the problem to everyone. On practice day, the whole team gathers in a conference room/team area, picks a pair, sets aside 90 mins to TDD the problem. After 90 mins, few pairs do a quick code walk-thru and explain their solution with important decisions they made during the session. Followed by an open discussion. I also recommend everyone checks-in their code in some common repository, so it can be used for reference by others.
Sample Problems: Next big question is, what problems do we use for Test Driving?
Usually I recommend starting with simple programs like:
- Games – Tic-Tac-Toe, Snakes and Ladders, etc
- Utility Programs – Convert Roman Numerals to Decimals, Diff 2 files, etc
Once you’ve done enough of simple programs, then I would suggest you take some large design problems from DesignFest and try TDD on them. The beauty of these problems is, they are quite big, can take up-to a week to finish it completely. Now we are talking real world, where
- We have limited time to solve/program large complex problems which needs to be simplified.
- Try to find a relevant System Metaphor that can help you visualize the design
- Do a quick and dirty, low-fi Interaction Design to understand how the user will use this
- Identify and prioritize the crux of the problem, figure out what is the most important, what will give us fastest feedback
- Further thin-slice the identified piece of functionality and
- Then try TDDing it.
This will truly help you get better at:
- Evolutionary Design
- System Metaphor
- Low Fidelity Interaction Design
- Thin Slicing
- Divide and Conquer – Simplify large problems by breaking them down
- Eliminating Accidental and (to some extent) Essential complexity (Embrace Simplicity)
Deliberately practicing this way for a few years, even though you are practicing TDD on your production project, will really help you appreciate the depth and benefit of this approach to development.