A workbook for practicing test-driven design (draft)
Summary: I wrote a workbook to help people learn test-driven design. Want to try it out?
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.
June 26th, 2007 at 11:12 am
This sounds like a great idea to me. I’m going to see if my group doesn’t want to work through it at our next weekly meeting. Thanks for posting!
June 26th, 2007 at 4:02 pm
Though it might bloat things a bit, it would be nice to have a set of pre-authored tests to be run after each requirement is added, so you could compare not doing TDD and TDD.
June 26th, 2007 at 4:36 pm
Great timing! We were just talking about TDD in our Java Users Group last night. Having some concrete real-life code and hands-on exercises would be very useful, and a great complement to the online Java curriculum the study group is going through.
June 28th, 2007 at 4:18 am
[…] Exploration Through Example » Blog Archive » A workbook for practicing test-driven design (draft) (tags: tdd) […]
June 30th, 2007 at 5:24 pm
You could turn the README into a doctest.
July 3rd, 2007 at 8:29 am
A different answer to (1) is open recognition that a great deal of programming involves thrashing around through conceptual space - and demonstrating that the fastest, most effective way to do that is with TDD. I demo’ed TDD at our local Code Camp on Sunday, and ran into (a little bit of) that. I was writing a half-open Range class and hadn’t adequately defined (in tests) the behavior where both endpoints are identical (is it empty?) And I thrashed about a bit - forcing it to be non-empty, then following a couple of refactoring dead ends before deciding that it really makes more sense for it to be empty. But the thing is, the audience got to see all that thrashing, and how much TDD and its comprehensive unit tests let me focus on the real design issues without worrying about (silently) breaking the code. I thought that little detour really strengthened my case for TDD, no matter how foolish it may have made me look.
July 5th, 2007 at 1:24 am
We tried it last night with our group (milano-xpug.pbwiki.com). I think it’s an excellent idea. I’ll have to write my own for my customers :)
My comment: many, including me, found the naming of some things confusing. “of” and “Like” read very well in client code, but carry too little meaning by themselves when you have to modify them. When I’m writing a new version of “of”, I find it difficult to remember what the contract of “of” should be. It’s neat, but it’s not idiomatic Java, as far as I know.
July 5th, 2007 at 1:33 am
[…] do anything without instantiating eighteen gazillion objects.” So Brian has created a (draft) TDD workbook, in which you get to add features to a real application that has already been developed for you […]
July 5th, 2007 at 7:30 am
[…] Marrick explains the difficulties in trying to convince developers of TDD goodness. His first approach is to dive into some of their […]
July 5th, 2007 at 11:21 am
Yes, my code isn’t idiomatic Java. I may add an exercise in which people change the names to fit their own style, which might lead to a discussion of how hard it is to get names right, how useful it is to adhere to the house style, what people should expect to help them get oriented to new code, etc.