Why Write Tests?


It comes up in more developer circles than dung beetles in crop circles. It’s at the forefront of any developer’s mind when they accidentally bump into someone who’s passionate about writing tests. It’s the question nobody understands and everyone is afraid to ask or answer. Why write tests? Hi, I’m Cliff. You may know me from time spent in an AOL chat session, or maybe you happened across my site by chance. At any rate, I’m gonna explain the madness behind tonight’s million dollar question.

We’ll start with the obvious, why don’t we write tests?

  • Testing takes time, time better spent developing working software.
  • Testing is what we pay QA for. Developers have better things to do, like come up with the next killer algorithm.
  • Tests break often and cost me man hours to babysit.

I could go on or days but that’s a good summary. Now here’s the reality check.

  • Testing takes time, time better spent developing working software.
  • How do you know when your software is working? Working is loosely defined by a system that meets the requirements. Do you care that your software meets those requirements?
  • Testing is what we pay QA for. Developers have better things to do, like come up with the next killer algorithm.
  • We pay QA to tell us when we developers have met the requirements and that the behavior of our software does not vary from the requirements over time or repeat execution. Are you bold enough to challenge to QA guy sitting right down the aisle from you to validate how well you’ve met the requirements? what exactly were the requirements in the 1st place?
  • Tests break often and cost me man hours to babysit.
  • Tests written after production code are very costly to maintain. If you read/change test code before you dive into the implementation you not only save years, you end up with reuse.

Now let me ask (those of you that don’t write tests) this. Have you ever reused a software component? I challenge you, right now. Go grab the last couple hours worth of development and use it completely external to the project you were working in. I dare you! To meet my challenge you have to use whatever component(s) you developed last without using your system clipboard and without any errors or crashes on the first attempt. Go on, I’ll wait here quietly while you silently fail. That’s the first challenge that I’d like to label “internal re-use”. It’s an actual measurement on how portable your applications internals are.

My next challenge is to reuse the last application you worked on with slightly different intentions. In other words, if your application writes to a printer make it blt graphics to a swing component. If it reads from a database make it read from an XML document, or from a memory Hashtable or Dictionary. If you have to touch a single line in your application programming logic (modifying the configuration is ok and encouraged) then you’ve failed. That’s another metric I’ll call external reuse. Its a measurement of how susceptible your application is to change.

These are the only two metrics that matter in software engineering. You should never measure how fast you complete a task or a project because in real software engineering a task is never complete and a project never ends. You should only measure how quickly/easily you can reuse stuff you or others have already written and how easy it is to introduce change into your project because these are the actual things that impact the time it takes to get a product to market.

So now, why do we write tests? Because they are the only way to measure the things that really makes software move from inception to implementation.