My usual style of teaching test-driven design is first to dive in and start writing some code, test-first, on my client’s code base. Sometimes I’ll do that one-on-one, sometimes by projecting the editor session for the whole team to see.
This works maybe a quarter of the time. When it does, it’s the best: it shows the watchers exactly what they’ll be doing. The usual reason it fails is that the code wasn’t written test-first, so it’s hard to do anything without instantiating eighteen gazillion objects. A team has to learn to deal with that eventually, but dealing with it as the very first thing really drains the appeal out of an introduction.
So at that point, I switch gears. I say, “The way you can’t create an Account without having a database connection and six other things is a real hassle. So let’s start over and begin building Account test-first. With some luck, you’ll not only see how test-first works, you’ll also see a good end-state. As you change your code after I leave, you’ll have an idea of what direction to change it in as you gradually move the code from hard-to-work-with to easy-to-work-with.”
When that fails—and I think it does about half the time—it fails for two reasons:
I don’t know about you, but when I’m starting to build a new app, I often spend a lot of time thrashing around, trying to find a good working division of responsibilities into classes. Eventually things settle down to the point where adding new features isn’t an Adventure in Reconceptualizing, but instead becomes what it should be: fairly straightforward. I’ve gotten more-or-less used to the turmoil (though I still wish I were smarter or more experienced). The problem is that it makes me look like a complete idiot to watchers. Worse: they may not blame me. They may blame the technique, decide it’s stupid.
They look at how much we’ve accomplished in an hour or two, extrapolate that to the size of the existing code base, realize they have a long slog ahead of them, and turn off emotionally because they were hoping for some quick ladder out of a hole years in the digging.
I can deal with the second problem in the moment. It’s the first I struggle with—especially as I do more work in mainstream companies with people who are not early-adopter types, who are more oriented toward getting training in procedure. So I’ve concluded that I need an example of test-driven code in my back pocket, an example I can whip out and extend. That lets me skip the embarrassing early bit, but at the cost of not building code that looks like it’ll fit in their app. A good tradeoff, I think.
So I wrote an example. To make it look less of a toy (while still being small), I made it deal with nitty-gritty number-format conversions.
As I was building it, I realized I could just write a document explaining the code, tack on a list of feature requests to implement, and release the whole thing as a self-study workbook for TDD. That’s what I’ve done.
Here is the workbook (6-page PDF).
Here is a zip file of the source (Java, only tested on Mac OS X).
What I want from you:
- Is this worth pursuing?
- If so, how should it be improved?
I might even turn this into a two-day on-site course in TDD. I’m not wild about such lecture/lab/discussion courses (they usually don’t have a big enough effect on team practice to be worth the money), but that’s the format in which a lot of people expect to learn. If the bulk of the course could be working through feature requests, we might all end up satisfied.