What would you like to see in a TDD demo?

Question

I am going to be giving a presentation on TDD and I always struggle with what to put in the demo when giving this presentation. I usually only have about an hour to do the actual coding portion of the demo so it can't be too extravagant. However, using a "classic" example (stack,queue) is a bit simplistic for most developers. It leaves them feeling as though this won't work in a real world solution.

There are a lot of concepts one needs to make TDD work well on their project besides understanding the core testing cycle (Test, Code, Refactor).

• IoC / Dependency Injection / Dependency Inversion
• MVP / MVC (in order to handle testing of user interfaces)
• Mocking

So the question is...

As a developer what kind of real world example would you like to see that incorporates these aspects and:

• Fits into an hour or so
• Doesn't overwhelm you
• Isn't so simple that you can't apply it to your current project

Answer 1

Here are some very simple examples that I can recommend off the top of my head. I've used some of these for introducing TDD to junior devs:

• For Ioc/DI - Provide a way to save a certain set of data in either a plain text file or an XML File. Point here is that the main application shouldn't have any dependency on the filewriters that you have
• For MVP/MVC - Make an implementation for simple data entry (e.g., First Name, Last Name, Birthday) that would work for both a web application and a console application
• For Mocking - Create tests that would mimic parsing a plain text file with a fixed data format, including error conditions -- without actually reading a file

Answer 2

I think people would find it useful to see the differences between state-based unit testing and interaction-based unit testing.

Answer 3

There is one common element in every TDD presentation I ever saw - they are way too simple to actually show the great value of TDD. They usually start with a simple app of less then 3 lines and shows how to add a feature to it.

In case you're not giving an introduction to TDD kind of presentation I would like to see how in a real application TDD helps you add feature.

Another element that is missing from most TDD presentations is Mocking and why should you use it. You should explain how isolating your testing code helps TDD (even without concrete examples).

Answer 4

What I would like to see is how to integrate TDD of new development (that integrates with) with our old code that was not written with TDD in mind.

Answer 5

I once sat in on a demonstration where the speaker had a few of us come up and develop a simple calculator using TDD. It's a simple enough example to be grokked immediately by anyone, but just complicated enough to illustrate how valuable TDD methodology can be.

Answer 6

A TDD Demo that might be not-too-technical.

Here is the kind of requirements we get a lot of.

1. Get data from a CSV-format file (user-supplied spreadsheets, and all the problems implied by that)

2. Pluck out the relevant fields.

3. Create an instance of some application class (an "Employer" or an "BusinessThing" or a "DomainSpecificEvent" [don't want to use real names from my domain, but you get the idea.]

4. Exercise that class to do some value-added processing.

5. Ideally, persist it in a database, but you'd run out of time and have to build mocks and blah-blah-blah.

Here's the outline for the presentation.

1. Review some requirements (get data, do calculation, persist in DB). 5 minutes.

2. An architecture (read via CSV, create business domain entity, persist). 5 minutes.

3. Some UT's for Business Domain Entity -- load, calculate, display, provide keys, summarize, whatever. This can take 15 minutes to define some tests. Then 15 minutes to define the class to pass the tests.

4. Some UT's for CSV Parser -- read file, ignore headers and footers, find appropriate columns, create entity (use Mock for this.) Then the class that uses csv to do these things. This can take 10 minutes to define some tests. Then 10 minutes to define the class to pass the tests.

5. Maybe an integration test using the unittest framework. Reads a CSV, emits entities (not mocks). Another 5-10 minutes.

Time should be about up.