Demonstrating TDD

by Jeff Langr

September 15, 2008

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 (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

Share your comment

Jeff Langr

About the Author

Jeff Langr has been building software for 40 years and writing about it heavily for 20. You can find out more about Jeff, learn from the many helpful articles and books he's written, or read one of his 1000+ combined blog (including Agile in a Flash) and public posts.