tags:

views:

533

answers:

12

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.

+1  A: 

How about a simple math class, with addition, subtraction, multiplication, and such?

Henrik Paul
Disagree -- folks new to TDD say that "it won't work in the real world" where things are "more complex" than an example that does math correctly.
S.Lott
+3  A: 

If you have a perfect example from a book, then you should use it and promote the book. No author would object to that.

Aside from that, I attended a TDD presentation a few years ago where the example was a simple calculator and it worked beautifully.

Bill the Lizard
+2  A: 

I would try to find something small from a wellknown domain. I recently gave a presentation on BDD / TDD based on ASPNET.MVC. That included one controller, one action and a view model. That also gave me the opportunity to introduce a dependency container and a mocking framework.

Thomas Eyde
A: 

I'd suggest you buy yourself the book Test driven design by example from Kent Beck.

The book almost completely focuses on building one class through TDD.

Lieven
are you talking about the Money class?
dfa
I believe it was.
Lieven
I really didn't like the second example (xunit) though. It was hard to follow for someone who doesn't know TDD at all and isn't familiar with xunit.
Meta-Knight
+5  A: 

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

Noel Kennedy
Though I was looking for a non-published TDD example, a lot of people mentioned Beck, and what you said about the money example is what I'm looking for. I'm also ashamed that I never bought his book...<sigh>
SergioL
+2  A: 

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."

Yishai
+1: A simple mock helps show how TDD works in complex cases.
S.Lott
+2  A: 

TDD problems has a list of problems, ranging from simple to less simple.

Some have a list of tests to start from no solution yet.

philippe
+1  A: 

Another classical example from the TDD / Extreme / Agile community is the Bowling Game example; I seem to recall it has been used in both Beck and Martin, as well as multiple times at xprogramming.com for examples and explorations of different techniques within TDD.

Tetsujin no Oni
+1  A: 

Go out on a limb and take requests from the audience. :)

JP Alioto
+1  A: 

If the goal is selling TDD, you also want to show a small refactoring of a large test base. It is easy to make it work with small samples, most developers buy into that now. There is much more doubt about scalability. An avanced topic would then be how to handle a large base of legacy (no unit tests) code.

A simple card game would be nice, especially as you can provide some visual representation of the result

And I assume you are going to use a coding dojo as presentation form, aren't you? No fancy powerpoint. If the public is non-programmers, use the excel sample

Stephan Eggermont
+2  A: 

Three I like, in roughly increasing order of difficulty:

  • Range (of integers; implement isEmpty(), contains(), intersects(), length())
  • Natural Sort
  • Snake

If I had half an hour, I'd do Range; 90 minutes, probably Natural Sort; more: Snake. Depends on the audience, though.

Carl Manaster
A: 

Roman numerals. Count non-comment lines of source code. Towers of Hanoi. There's plenty of ideas out there.

David Plumpton