Test-Driven Development As Part of the Process

Noel Rappin, Monday, August 20, 2007 @ 10:36 am

About a year ago, I wrote this post about test-driven development,
which has some tips for TDD from a developer point of view. I thought I’d
augment that a little bit by offering some thoughts about TDD from the larger
project perspective.

The Long Term Starts Tomorrow

There’s a general sense that automated testing is something you do that costs
you time in the short term for a long term benefit. This is probably true to
some extent, although I’d argue that if you are really seeing a short term
time loss from TDD, then you probably could improve your practice some.

The larger point is that referring to “the long term” makes the benefits seem
like something that will happen in the comfortably remote future, along with
flying cars and space elevators. Usually, though, the long term starts the
first time somebody asks you to add a feature or fix  a bug. Which means next
week. Or tomorrow. Or later today. The benefits accrue faster than you think.

Retrofitting for Tests Never Quite Works

There aren’t a whole lot of programming tasks in the agile world that are as
as annoying and frustrating as adding unit tests to existing code. The
existing code never has all the structure and hooks needed for good testing,
which means refactoring is needed to get any useful testing in. Of course, the
existing code doesn’t, by definition, have tests, so there’s danger involved.
Inevitably, there’s some monstrously hairy corner of the code that nobody
wants to touch and it just hangs there, untested. You’ll almost always also
see that design decisions that were not made with testing in mind are not
particularly amenable to allowing unit testing later on. The cost of
retrofitting accrues faster than you think, as well.

Refactoring is Just As Important

The test-driven development process is a three step process. Test, code,
refactor. The refactor step gets left off sometimes, but it’s just as
important as the other two in getting the full benefit of TDD. There is an
analogy to continuous integration, where the idea is by integrating in more
frequent, smaller chunks, the overall integration costs go way down.
Similarly, by doing frequent, small refactoring, overall cost of refactoring
to keep the code clean goes way down. It helps tremendously to do the
refactoring in the tight loop, when you are most familiar with the code and
the tests you’ve just written.

tech development

Comments

• Leave a comment
• Comment feed for this post
• TrackBack URL

None so far.

Leave a comment