The Immeasurable ROI of Unit Tests

One of the biggest problems with advocating Unit Tests is the fact that the return on investment is transparent and immeasurable.  In his blog {codesqueeze}, Max Pool offers a simple but elegant way to increase awareness of how much time is wasted when you don’t Unit Test.

We have a general idea how much time it takes to properly unit test a piece of software.  It can be worked into the estimation worksheets up front when a project starts.  What we can’t estimate is the amount of time saved on bugs and problems prevented by unit testing.  This inability to quantify the benefit of unit testing has led clients, architects, and even engineers to question their worth.  If you are one of the people who forgo unit testing in the belief that the costs outweigh the benefits, I urge you to take Max’s Challenge:

I give you one simple challenge - start counting your “Oh S**t” moments.

There are many moments you can start counting.

Oh S**t I …

  * didn’t code that right (the very first time)
  * just broke previously working functionality
  * fixed a bug, but created another bug (or two)

How many “Oh S**t” moments would you have in a day? In a week? On a project? They can really add up. Most importantly, you can measure how much time you spent fixing things you didn’t need to.

It may sound corny, but this is very similar to an experience I had that truly turned me onto unit testing (specifically Test Driven Development).  I was given a simple bug fix for a legacy project where a collection of objects were supposed to be sorted by a Date field.  When the application ran, however, the dates were in what appeared to be a random order.  The project itself had limited test coverage, and I didn’t bother to write any new tests to help me with my bug.  It was just a simple sorting problem right?  After nearly an entire day was devoted to searching the use cases, piling over code, examining collection utilities, and rewriting equals() and compareTo() methods, I was still at a loss.  Everything looked correct - it just wasn’t working!  So I finally decided to write a unit test… and found the problem in a matter of minutes.  The date was being stored as a String instead of a Date.  The objects were in fact being sorted - alphabetically by their date, which had the annoying habit of putting April and August first.

Time spent ineffectively trying to fix code that wasn’t coded right (the very first time) - 6 hours.
Time spent writing the unit test, identifying the problem, and fixing it - 1 hour.
The different in time - 5 hours (500% ROI).

Seeing the light and using Unit Tests from now on - Priceless.  Now how much time do you spend on Oh S**t! moments?

Comments

Returning visitor? Please login or register.

Interesting blog.

Recently I wrote 2 blogs, one to encourage people to write more automated unit tests and other to make them aware of the costs associated with unit tests.

Unit Testing Dilemma: Should I Invest or Not? - http://blogs.agilefaqs.com/2011/11/01/unit-testing-dilemma-should-i-invest-or-not/

Importance of Unit Testing and Test Driven Development (TDD) - http://blogs.agilefaqs.com/2011/11/01/importance-of-unit-testing-and-test-driven-development-tdd/

Naresh Jain Posted on: Nov 06, 2011 at 06:14 AM

Leave A Comment

Please help us stop spam by answering the question below: