The Case for Unit Testing and Return on Investment

ROI is a hard matter when it comes to software development.

A huge number of managers simply don’t get the case for Automated Unit Testing; no matter how many times they’ve heard about its benefits;
no matter how many times they have dared to say (liar…) that their teams are doing unit testing.

Even worse… there are still a huge number of software developers that still don’t get it.
And a lot of technical managers; not only your usual “ pointy haired boss ” but those technically fluent that have won your respect over the years… not even they seem to fully understand that automated unit testing is a direct money saver.

So I’ll write about a small event in a project I’m involved right now (and I mean… now…).

The core of the system has got a coverage of 100% of the lines.
Even though that’s not as good as it can get, it makes me feel confident, and makes it harder for anyone to justify *why* is his code missing full coverage.

(Don’t get scared. It’s not hard to get coverage if you stablish the policy from the beggining, and it’s easy to get the team involved if you bring them the tools to do it)

Well, back to the story, this morning, I’ve started myself coding a small change for that project:

Some contents are stored in two languages, and our client have now asked for the languages to be four. “No problem”, I thought. “I’ll scan that code” (not even 500 lines counting code and tests) “and extend the proper parts to hold the new fields. I’ll do it myself so I don’t disturb the development team.”

It took me about 30 minutes to get the fix done and the tests still were running OK.
So I thought… “Should I write some specific testcase to test this new fields?”

My first answer to myself was “Naaaah… the code is right, I’ve done it carefully. The existing tests on the matter still pass. Don’t be test-obssesed, Jorge!”

But… just for… obssesion, right… I did change some values in the test data to hold some values in the new languages, added some assertions on that new data, and run the tests again.

Some tests (not directly related) started failing miserably when trying to consolidate the contents stored in the new languages.

It took me another 10 minutes to fix and test it.

Now, let’s think about Return on Investment…

Let’s say that I don’t write that last test.

Let’s say thas this code would have passed the integration test (it would indeed, because nobody will care about thoroughly testing french contents beyond “yes, they appear in the proper place”).

Let’s say that, once the code is in production, somebody discover that french contents don’t seem to be taken into account when reporting to the management.