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.