Olof Bjarnason, a poster to the Yahoo! test-driven development list, has compiled a list of TDD demonstration/exercise problems. The list currently appears at http://sites.google.com/site/tddproblems/all-problems-1 (thanks George!).
TDD demos are often dismissed as trivialities. A frequent claim is that they’re not “real-world” enough, suggesting that TDD can’t scale. I’ve moved through a few different preferred demos, but I’m always seeking out new and better ones. Currently I prefer a multi-map (key -> list of associated values). I’ve used a multimap often enough in “real” applications, it’s a short demo, and it covers all of the important bases in demonstrating TDD rudiments. The only downside is that a similar construct already exists in Apache Commons.
So what are the important bases to cover? I think a good first TDD demo should have the following characteristics:
| Can be demoed in 30-45 minutes | If you weren’t demoing, you’d be able to test-drive the solution in 10-15 minutes. Any shorter of a demo and you tend to blow past much of your audience. |
| Has some “real world” relevance | This is why I don’t demo the bowling game |
| Isn’t too trivial | Stack is just a bit too small |
| Solution requires no contrivances | For example, you shouldn’t have to say “we’ll use some dummy data here” |
| Allows for a continually incremental solution | Green bars come every few minutes (reinforces “red first”), after at most 3-4 production lines of code |
| Requires no major intuitive leaps | This rules out, say, the Roman numeral conversion, but doesn’t mean you can’t use that for a later lesson. |
| Solution provides continual opportunities to incrementally refactor both tests and production code | An overloaded interface on multimap (size & isEmpty) can help bring out a key point here. |
| Can demonstrate the choice to test behavior over testing methods | Provokes a discussion around test method naming and potentially BDD concepts |
| Can emphasize “fake it ’til you make it” | Hard-coding forces more tests, and also allows faster green bars. Specific solutions -> generalized solutions |
| Includes at least one exception-based (negative) test | Opportunity to discuss test-driving alternate paths, as opposed to including them as an afterthought |
