TDD Makes Software Go Faster

One of the gripes I hear about TDD is that it takes too much time. People look at the idea of it and think, “So I have to write code and tests and update the tests when the code changes? WTF?”

My message to you is: TDD takes less time, not more.

Today’s example: I’m writing some code that uses a parsing library written by a cow-orker. He’s a sharp guy, and the library generally works well, but it has a couple of undocumented behaviors – they’re mostly benign, and probably work for other users of the library, but for me it’s stuff that would result in misbehavior way up the call stack, or in another module entirely.

While I’m test-driving the code that uses this library, I notice the library itself does not have automated tests. The natural-feeling thing for me to do here is to test some sample calls to the lib to make sure it does what I expect. I know it’s not exactly canonical behavior to test outside libs that are assumed to be functioning, but it is good form to write tests that teach you about the system you’re building, and I needed to learn whether this library was going to parse my input in the way that I expected. The documentation wasn’t there, I wasn’t going to figure it out by inspecting the code (which is relatively complex), so tests it was.

Surprise, surprise – I found out that the library did NOT behave as I expected in every case. Had I not taken twenty minutes to write tests to introduce confidence in the parts of the system I didn’t know well, I’d probably have spent a couple hours debugging and looking in the wrong places for the problems I was having downstream. It also led me to a relatively simple solution where I extended the library class and just overrode the elements related to my handful of problematic cases, without changing his library or breaking code that depends on it.

As an added bonus, not only do I know what the documentation does not tell me, but I’ll also know if and when my colleague makes changes to his library that break the expectations of my code.

So I’ve reduced debugging time, increased my confidence in my code, and protected myself against future changes. I see it time and again – the time saved by writing the extra test code is well out of proportion to the time spent writing it.

There’s an exception here for developers or shops that are fetishistic about 100% test coverage, and do not judiciously use automated testing to learn about the system, drive design, and catch regressions. Writing tests to cover trivial/obvious code (i.e., writing tests that do not teach you about the system) is a time-suck. I’d avoid it, if I were you.

As long as I’m raving about TDD, I have to recommend the work of Kent Beck. I follow him on Twitter, I read his blog, and his book on TDD changed how I write software – I count it among the indispensible books on my shelf, with the GoF Design Patterns and Knuth. Check him out if you’re interested in deep thought about how software gets made.