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.

3 thoughts on “Why Write Tests?

  1. Yea, but. So? Management won’t buy any form of logic regarding time spent on writing tests. And, most developers know they should write some tests, but they don’t or can’t. No amount of arguments will change “culture”. I have been in software for years. I’ve yet to see a unit test. In fact, most of what I’ve worked at was untestable! I could not change the dev culture though I tried. What’s scary is that software is more and more controlling the world, I hope embedded developers don’t eventually become like business developers.

  2. Josef,

    You’re absolutely right, except for one thing. You’re wrong. Let’s start with, “most developers know they should write some tests, but they don’t or can’t”. Yes they don’t but no they can.

    getPriorStatement.replace("can't", "won't");

    Now let’s followup with, “No amount of arguments will change ‘culture’.” There is a finite amount of arguments that fail to change culture and once you exceed that limit you end up with radical change like Hilary Clinton in the primaries and Barack Obama in the oval office. Presidential debates aside, it’s not culture you need to change, rather it’s perception. Once you adjust the perception of a select few the masses of culture will have no choice but to follow.

    Then we have, “most of what I’ve worked at was untestable!” Impossible! I too have been in software for years. I’ve never seen code that couldn’t be tested. I’ve seen code that was very difficult to test, code that was brittle and not amenable to change, but even the ugliest code bound to static method members could be tested.

    Herein lies the heart of the problem, perception. When something is perceived as difficult it is avoided. The concern is the ROI isn’t worth the LOE. Taking this problem, like any other in software engineering, and turning it on its side you gain the proper perception. That is to say the LOE of testing is roughly less than or equivalent to the LOE of changing it. Understanding that you must and will change it repeatedly over it’s life time then you’ll understand that writing the test is only fractionally as expensive as maintaining it.

    I totally understand your point and your pain. I fall victim to the same perception problem very often. Many times I want to huff and puff blame about “the culture” and “the people at the top who ruin everything” when instead I should be writing the ugly testling. Once the testling is in place I get such a sigh of relief from the ability to whimsically refactor to my heart’s content. I also get very big payback from both understanding the code’s intent and the resulting decoupled components that can be redeployed in other ugly parts of the code. So do I really need “the culture” to change in order to write a test?

    What I’m really saying is the problem isn’t “the man” or “the culture” or “the establishment”. The problem lies in the hearts and minds of every developer that knows what he/she should do but doesn’t.

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