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|