(Tue Jan 04, 2005) [/TDD] #
While teaching my Test-Driven
Development with JUnit workshop, I hand out red and green pipe
cleaners. One of their purposes goes with the JUnit red and green bar
theme: You can hold up a green one to let me know that something I
said really touched an area deep inside your brain or a red one to let
me know that I need to backtrack so I don't lose you. It has proven
to be a fun way to get feedback.
Another purpose of the pipe cleaners is to keep the hands of the
kinesthetic learners engaged while the auditory learners are listening
and the visual learners are watching. The workshop includes lots of
hands-on exercises (it's a workshop) so that everyone learns
by doing, but as a kinesthetic learner I know how important it is to
fidget with something during the lecture parts of training.
Indeed, although it may appear that they're not paying attention,
making shapes out of pipe cleaners actually heightens the
concentration of kinesthetic learners.
Just before the holidays, I had an opportunity to teach TDD to a
great group of folks at Lands' End. When the last question had been
answered at the end of two days, Ann had brought many of our names to
life in red and green. The final touch was a Christmas tree and candy
canes. She had also completed all of the hands-on exercises, usually
before anybody else. It became a running joke that Ann couldn't sit
still without those pipe cleaners, and I suspect she wouldn't have
learned as much either.
(Tue Dec 28, 2004) [/TDD] #
Tim Bray weighs in on his experiences with TDD in Yet Another TDD Sermon. I have a lot of respect
for Tim. He says TDD helps him write better programs. I'm obviously
already drinking the TDD kool-aid. But if I weren't, why wouldn't I
want to try it to see if it helps me write better programs?
I'm happy to see this story play over and over again. I gave two
TDD talks in Raleigh, NC last weekend. Both were well attended
and folks were enthusiastic about writing more tests on their
projects. This TDD stuff is going to catch on, I tell ya.
(Tue Dec 28, 2004) [/TDD] #
Ron Jeffries, in his online article (err... upcoming book) Adventures in C#: Using NUnit,
sums things up oh so nicely in this statement about test-driven development:
It occurs to me as I write this that in the course of this book, you will
probably encounter examples of doing things in ways that seem almost
obtusely simple. I assure you that I'm not doing it to make the book
suitable for third-graders, nor because I myself am also simple. I work that
way because in the half-dozen years I've been doing Extreme Programming,
I've been working in simpler and simpler ways, and my work seems to be
getting better and better. So, please, when you see something here that
looks odd, give it a try. Often I think you'll find it interesting.
I've been seriously practicing test-driven development for over a year now.
It hasn't all been in an XP setting, nor does it need to be. Indeed,
I think TDD and continous integration bring a lot
to the party on their own. Unfortunately, I'm afraid all too often the
baby is being thrown out with the bath water.
When I'm letting tests guide my way, I almost always find something
interesting that wouldn't have been illuminated had I just slapped
down the code that first popped into my brain. At first it felt awkward
and a bit silly: Write a failing test, write just enough code that makes
it pass, then refactor in the safety of that test. Writing just enough
code is sometimes the silly part as I try to tease out the simplest
solution. For some reason it's always tempting to speculate and in the
process over-engineer. Yet with TDD I'm usually amazed at how little code it
actually takes to build something of value.
In keeping with the TDD rhythm, I'm actually cranking out more code
than without testing. And I know it's always working the way I intended
it should. And the designs tend to be more responsive to change than when
I was coding only after dreaming up a pattern-compliant design.
I had to rewire my brain by listening to the
tests. I'm sure glad I did.
(Tue Dec 28, 2004) [/TDD] #
I had a great turnout for my "Test-Driven Development With JUnit"
talk this weekend at the
No
Fluff, Just Stuff symposium in sunny Seattle, despite going up against
Glenn's stacked
deck at the same time. ;-)
It's always rewarding to get stellar reviews on a talk, but this time I got a
few extra goodies. A number of attendees used the word "convincing"
on their evaluation form. Now it's not unusual that folks give TDD a whirl
after listening to me extol its virtues. After all, with all those green bars
flashing by you can't help but want to pop one yourself. But this is the first
time I've received nearly-unanimous reports that the talk was convincing.
So on the plane ride home when I was sifting through the evals, I started
thinking about what was different this time. I'm always looking for
opportunities to use feedback as a resource. The results of every talk I give
get piped into the next talk. And I've given this talk about a dozen times, so
it's been... err... mercilessly refactored.
Earlier in the week I had taught a
course on TDD
using JUnit to a bright team of QA and development folks. Their enthusiasm no doubt
kept me wired through the weekend. I'm very much looking forward to watching
JUnit and TDD take root on their project. Perhaps that enjoyable experience
got me started on the right foot.
But in general I'm just really passionate about TDD. When I'm up there
talking, I'm not shy about telling you how insecure and unproductive I am
without it. I guess I've never been too shy about sharing my failures. What
do I have to hide? Indeed, the more I hide the less I learn. Example: Oh sure, I used
to write unit tests after my code seemed to be working, but I loathed doing it
and my tests weren't all that good. I was always hurriedly testing in hopes of
getting back to the creative process of writing code. (Maybe I'm a bad
programmer, methinks.) Only now have I discovered that writing tests first is
part of the creativity. Better yet, I'm writing better tests because I'm actually
enjoying the design benefits and the freedom the tests afford me to change code with impunity.
And I've been studying and practicing object-oriented design and patterns for
over a decade now. I've got all the books and t-shirts to prove it. But when I'm honest with myself I know that most of that
time I was really frustrated. Too often my beautiful UML designs turned ugly when
I tried to codify them. (Maybe I'm a bad designer, methinks.) It's a
bit hard to swallow, but I think
I've learned more about OO in the last two years since picking up TDD than I
did in all the years previous. But more importantly, I'm having fun with it
because my designs are actually working. They're simpler, yet they still
exhibit the qualities we associate with a good design: high cohesion and low
coupling.
So here's my advice if you're trying to convince your team to use TDD: Just
honestly tell them how it's working for you. And then stop talking. Don't
worry about trying to convince them that TDD should also work for them. Yeah,
I know that the books say it should and x number of programmers can't be wrong,
but forget all that. Our industry is already polluted with tools and
techniques that were supposed to work. Folks have to decide for themselves to
try TDD and then shape it into their own technique -- based on their context.
You can't do that for them, and they'll hate you all the more if you try. And
if listening to a so-called "OO expert" talk about his frailties helps, I'd
love an opportunity to tell them, and show them, how TDD is working for me.
(Tue Dec 28, 2004) [/TDD] #
Did you make a New Year's resolution to start writing more tests and
enjoy better designs as a result of writing tests first? How's that
going so far? If you're having a difficult time getting started or
making that resolution stick, don't despair. This stuff takes practice.
To help you get started, my
"A Dozen Ways to Get the Testing Bug in the New Year"
article is now available on
java.net.
It gives you 12 practical ways to start (and keep) writing tests,
regardless of your development process. It also explains how
writing tests first results in the emergence of better designs.
I hope you find it helpful and encouraging.
By the way, I love the "delicious" graphic designed for the
article. Have I mentioned just how outstanding the
java.net staff is to
work with?
