Testing Overhead

I was enjoying a sandwich with my friend Lindsay the other day when he asked an age old question:

“How much extra time do you think Test Driven Development adds to the build process of a software project?”

An excellent question, one I think about all the time. Once we established what he meant by build process my answer was pretty easy:


As a test driven developer, when was the last time you were burned by a NullPointerException? I haven’t seen one in my domains for a couple of years. You catch that stuff at build time through the effective use of testing. You know the state of your objects before they start interacting with other objects.

With some research, I’d wager that Test Driven Development actually saves time. The tests that drive my software were written by a customer. If my tests (and subsequent software) satisfy what the customer has written, I’m done. Finished. I can remember thinking I was done solving the customer’s problem only to later find I didn’t fully comprehend it. When they write the tests and I code them, we’re both aware of their expectations. That saves a tonne of time and better than that, it frees up my time to solve more of their problems.

If you’re new to TDD and looking for a good book to take you through the preliminary steps, try Kent Beck’s Test Driven Development: By Example


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s