What would be a good task for a test-driven development presentation?

Question

Possible Duplicate:
What would you like to see in a TDD demo?

What is a good sample class to demonstrate TDD?

I'd like to prepare a one-hour talk on test-driven development, using Python. But rather than describing what TDD is (and giving little examples), I'd like to choose some user stories that could be implemented using TDD in a little less than an hour, and do so (with running commentary). At the end of the hour I'd like to have a reasonable number of passing unit tests that show that the set of user stories has been implemented.

Can you suggest some interesting user stories that would be suitable for this exercise?

I read Kent Beck's Test Driven Development: By Example years ago, and IIRC the second example was the creation of a unit testing framework in Python, using TDD. That's certainly an interesting example of bootstrapping, but I think it may be too confusing (or too "inside-Baseball") for an audience that will likely contain people who have no experience with unit testing.

Note that I don't plan on writing the tests and code for the first time when I give the presentation. To pull this off properly I'd need to practice this several times, so I can do it live without long pauses to think and avoid the temptation to pursue tangents.

Answer 1

Compilers / Interpreters have very strict interfaces that are good for writing tests for. And you can define the behavior in an absolute way before development. They are well defined black-boxes with a simple input/output fail/succeed/warn model which is good for testing too.

Maybe use the example of a desk-calculator or RPN converter or something simple (doesn't need to be a full JavaScript implementation to be representative of the theory)

You can use examples of 'undefined behavior' being tested/designed out.

Validating that it can read all permutation of syntax with the right semantics by feeding it script and validating the output.

Also, tests can be created directly from reported bugs, to stop them recurring.

All tests can very easily encapsulate the design right from the off. For example:

1 + 1 outputs + 1 1

And so on.

You can write it all in Python. Just to show what is going on, maybe represent the black-box as a module with Python test-cases.

Answer 2

Who are you selling to?

To managers, I think the TDD aspect of automated unit testing is attractive. Come up with some examples of types of code that can easily be unittested. One example is anything that transforms an input into an output based on a strict set of rules. These include any kind of decoding of messages, parsing, etc.

You can show some slides with case A, no test-driven development. The bug is not caught early enough, customer finds bug, gets angry, throws your stuff out the window. Then show case B where the studious developer finds the bug, and many others, making the customer happy. The customer stays happy because in case B the test is rerun on every build/release/whatever.

Build from that how testing then drives better design and more maintainable software. These points seem to excite the powers that be less so, but its still important to point these out.

Once you get everyone excited, be sure to say what can't be tested.