I need to give a short presentation (2-4 hours) on Test-Driven Development and need to come up with a small class that I can build using the TDD methodology. The class has to be relatively small, but "sell" the concept of TDD.
If anyone has read James Newkirk's book, Test-Driven Development for in Microsoft.Net, the Stack example is perfect. It’s a small class, has a manageable list of tests/requirements, and the creation process sells TDD (IMHO).
I don't want to use the Stack example or similar data structures (queue, lists, etc) for fear on impinging on Newkirk’s work.
So, I’m looking for a few good ideas for a sample class.
Thanks.
In short, the premise behind TDD is that code should be continually tested and refactored. Kent Beck teaches programmers by example, so they can painlessly and dramatically increase the quality of their work.
It can be succinctly described by the following set of rules: write a “single” unit test describing an aspect of the program. run the test, which should fail because the program lacks that feature. write “just enough” code, the simplest possible, to make the test pass.
How about using the 1st section of Kent Beck's Money example. It starts out very simply but when you arrive at addition of two different currencies, TDD suddenly shows you the falisity of up front design, or YAGNI (you aren't going to need it).
Another good example is uncle Bob's bowling score TDD example. I think this is a good example of how a TDD narrative brings you to a clean solution that would have been explicitly unapproachable via an up front design.
To make it a really exciting presentation, up-front you could challenge the audience to design the two scenarios using whatever methods they find appropriate. You then would show the TDD way of designing them.
The real WTF moment for me with TDD was when Beck removed the two subclasses of Money, and the tests worked. This is not a trivial action; the man deleted two classes! The confidence to do something like this can be found only by two means.
1) gathering all the senior players in a code base and running through scenarios, followed by an extensive follow through to confirm it works
2) TDD
=D
If you have time for it, I would pick an example with an external dependency of some sort that is going to get abstracted in the test. Either a database, calls to a GUI, calls to a remote system, etc.
The reason is that one of the blocks to TDD is that the example seems too self contained. "Sure, when everything is a self-contained unit you can unit test, but when I have 15 systems to integrate, what is the point?" kind of thing.
I would also at least show one example at the end (look at Michael Feather's book Working Effectively with Legacy Code for how-tos) of migrating an existing class to bring it under TDD. Don't dwell on that as an example, but odds are your audience will be thinking about how to migrate the class they wrote that morning, no reason to let that fester as an "unmentionable."
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With