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

Answer 1

For me, the best advantage to adopt the unit test is that I can change my coding behavior to make it more testable, in another word, in more loose coupled way.

if you cannot practice unit test in your real project due to the management issues, I would choose to practice on some small toy project, just to force yourself to get a way to write testable code even there is NO unit test.

My own 2 cents.

Answer 2

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 3

My short and incomplete advice would be to:

• Just change jobs. A company whose managers give that sort of answers is going to fail anyway, and soon. Get out before it's too late.

• Reverse the blame game. Make an official statement every time something gets released without unit testing that it has been done so, and that you are not guaranteeing it's bug-free.

• Write down the time you spend on tasks, separating bug fixing after failed deployments, and total it against a (potential) time allotment for writing unit tests.

Answer 4

Now there is a resource to help. A modern list of use cases, tangible evidence for TDD.

Do you need to convince your boss or teammates that TDD is being used? That it's not some theory? That it's not just heir say?

Now you can, check out WeDoTDD.com, a list of companies that TDD and the stories behind those teams.

That's exactly why I created this site, to put to rest the arguments around "TDD proof" and "Does TDD work" and "Who is doing TDD".

You can also learn a lot about the topic itself there by reading the stories behind these companies and teams practicing it.

Answer 5

If unit testing, I'm assuming you're talking about TDD here, is that important to you you should use your own time to write them (assuming you have time). If you do, keep a record of how much time you actually spend writing them and after they've been in place for a release cycle or two go to your managers with some data.

If the answers you've posted are really what your managers are saying then you work for idiots and perhaps some hard data can sway them. Given the market, quitting isn't likely an option and playing office politics won't get you anywhere (or improve the quality of your code).

Until your managers understand that TDD IS NOT solely about preventing bugs or "testing" they will NEVER get it. TDD is about design and overall code quality.

You have to show them. If they can't be persuaded then I would start looking. Quietly ;)

Answer 6

Don't sell management on a particular approach; that's just going to be difficult and isn't really going to buy you much. Whether or not your management chain appreciates unit tested code doesn't matter.

Sure, unit testing your code has a lot of benefits associated with it, but don't rely on management buy-off to write your tests. When people start seeing results, they'll flock towards The Right Thing.