« OnlyForward | Main | Open source leads to outsourcing? Hardly »

TDD: why half your time spent writing tests is a good thing

Jon Udell highlights a new tool that supports Test Driven Development (TDD):

...but when up to half of the output of a full-blown TDD-style project can be test code, we're going to want to find ways to automate and streamline the effort. The art and science of software testing

Very true, and that figure should not be considered negative or problematic - simply a point of leverage (or in Agitar's case, an opportunity). The future of software development is often said to be in code generation and meta-modelling. Yet those technologies have a ways to go to match the productivity gains made by the smart application of automated tests.

One aspect of TDD is that it captures knowledge about the system, executable knowledge, which was previously transient, unavailable or simply thrown away. Without TTD or test-first, this 50% output/effort was probably never captured. It was spent interpreting print lines and on hours poured over the debugger - neither of which result in reusable knowledge. Time spent in a debugger is not recyclable, not repeatable, not resuable by others - a debugger is the tool of last resort.

Without TDD probably less than 20% of your time is in writing code. It's in eyeballing print lines and debugger output, reading an ill-formed spec, being in more and more meetings because things are falling behind, doing everything except adding functionality. Sure, the first month you cranked it and it felt good - we've all been there. But without the continual investment in tests, the ability to keep going and sustain pace falls off - dramatically. After 3 months, the first month doesn't matter - things just averaged out. Chances are that's the best it will get; the pace will continue to fall off thereafter.

I remember someone saying to me once - "The problem with JUnit is you spend half your time writing tests." At the time I didn't have snappy comeback. But half your time spent writing tests - that's not a problem, it's a feature. There's a good chance 30-40% of the rest of your time is spent passing those tests - that is, adding functionality. Depending on how you look at it (and how cavalier we're being with statistics), that's a 50-100% productivity improvement. One compounded by the fact that anyone else can run and read the tests to understand how the system actually behaves, at any time in the future, and by the fact that an evolving test suite along with refactoring continually defers the day when you cannot easily add new features and capabilities, because you fear breaking what's already there. That's design by inertia. We've all been there too.


January 26, 2004 10:52 PM

Comments

Trackback Pings

TrackBack URL for this entry:
http://www.dehora.net/mt/mt-tb.cgi/1146

Listed below are links to weblogs that reference TDD: why half your time spent writing tests is a good thing:

» That dirty little secret about programmer productivity from Developer Testing
Bill de Hora reacts to Jon Udell's TDD-article and observes that the 50% of time spent on coding, which the ar... [Read More]

Tracked on January 28, 2004 11:02 PM