Becoming a Better Programmer

Chapter 11. Testing Times

Quality is free, but only to those who are willing to pay heavily for it.

Tom DeMarco and Timothy Lister, Peopleware: Productive Projects and Teams

Test-driven development (TDD): to some it’s a religion. To some, it’s the only sane way to develop code. To some, it’s a nice idea that they can’t quite make work. And to others, it’s a pure waste of effort.

What is it, really?

TDD is an important technique for building better software, although there is still confusion over what it means to be test driven, and over what a unit test really is. Let’s break through this and discover a healthy approach to developer testing, so we can write better code.

Why Test?

It’s a no-brainer: we have to test our code.

Of course you run your new program to see whether it works. Few programmers are confident enough, or arrogant enough, to write code and release it without trying it out somehow. When you do see corners cut, the code rarely works the first time: problems are found, either by QA, or—worse—when a customer uses it.

Shortening the Feedback Loop

To develop great software, and develop it well, programmers need feedback. We need to receive feedback as frequently and as quickly as possible. Good testing strategies shorten the feedback loop, so we can work most effectively:

• We know that our code works when it’s used in the field and returns accurate results to users. If it doesn’t, they complain. If that was our only feedback loop, software development would be ...