The Value of Unit Testing

Question

Here are some typical answers(ranked in ascending order of corniness) I get from managers/bosses whenever I bring up the importance of having unit tests and code coverage as an integral part of the development cycle

1. "That is the job of QA, just focus on features and development"
2. "The application is not mission critical, if there are some bugs it's not the end of the world"
3. "We can't afford to spend time on unit testing"
4. "Try not to get too fancy"

In spite of having the best intentions of doing a good job, at the end of the day when time comes for the blame game, the burden finally falls on the developer.

It's all too often that I've seen that things break in production, some of which which could have been avoided by catching these bugs statically by running unit tests.

I just wanted to get a conversation going to see what peoples experiences have been and what is the best way to tackle this.

UPDATE: Thanks everyone for a lot of insightful advice. There are several answers that I wish I could select as the right answer.

Answer 1

Introducing unit tests into development process is like investment: you have to put some money up front to get profit later. Management should be more attentive to this analogy if you follow through with it: describe what investments are required and then lay down plan for profits.

For example: Investments:

• time spend to implement test infrastructure (no serious product unit tests can be possible without test-specific infrastructure code that streamlines product specific test patterns, test data creation/removal, etc.);
• time spend on writing actual tests;
• time spend on reviewing and supporting tests;
• etc.

Profits:

• no bug ever re-appears without a sign;
• no major features are released without unit tests passing;
• cycle development-qa-fix bugs is cut in half for majority of bugs: development-unit test-fix bugs;
• etc.

Answer 2

Most managers won't see the advantages of unit testing until they see it in action where it makes sense, so my advice, based on experience, is to take the ff steps:

1. Apply unit tests to recurring bugs - This is the best use case to prove the value of unit tests. When you have bugs that just appear and reappear every other build, the unit test will allow developers to see which changes caused the bugs, aside from alerting them in advance that a fix is in order. It's quite easy to demonstrate to management as well.
2. Apply unit tests to regular bugs - With the usefulness of unit tests now clearly demonstrated, several instances of recurring bugs disappearing in the long term should be enough to encourage everyone to use unit tests to evaluate all bugs, to prevent them from becoming recurring bugs.
3. Apply unit tests to new functionality - With unit tests making sure that old bugs don't reccur, and confirm that they are fixed in the first place, the next step would be to apply it to new functionality to ensure that bugs will be minimized. Make it clear that it is impossible to totally eliminate bugs.
4. Apply full blown TDD - The final step will be to apply unit testing even before coding, as a design tool that both helps in designing code and minimizing bugs.

Of course I'm not saying that this is easy -- what I had stated above is an oversimplification which even I struggle with everyday -- it's difficult to convince everyone.

If later you decide to move on to a different company, you may want to explicitly look for a company that practices TDD.

Answer 3

People listen to their wallets. Show how much time you can save by catching bugs early on. Translate that to dollar-savings.