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.
