How to convince a project sponsor that all functions in your code should have unit tests

Question

Non technical people in most cases do not see any value in writing unit tests. They just want to have basic code completed and do not spend money and time on such things like unit tests. Later, every day they just to ask to fix a one bug more. Projects are missing deadlines and they still don't see value in good automated tests.

Answer 1

Try using an analog. Ask them if they would like their kids driving Volvos or Kit cars made by some guy down the street. The answer should always be the Volvo. Then ask why? The answe ris it is more reliable and safe. How do they know. The answer is testing. All automobiles are tested to an extreme and the cost relflects that. If they want there software to be as reliable as possible as possible they need tests. (Or they become the crash test dummies)

Answer 2

Selling complete unit testing after development has already started is very hard. I would even go so far as to say that it is often impossible. If you don't get buy in from all project stakeholders for complete unit testing up front, then you should be happy for whatever unit testing that you can squeak in.

Answer 3

The best way is to not get so technical with "non techical" people. Just build it into the delivery time without going into details.

On the flipside, it sounds like the project deadlines were not realistic to actually build it.

Answer 4

@Craig, I thought about the car analog as well, but I think the analogy falls apart since it sounds like there is already testing present in the project and it is simply a matter of degree. In that case the car analogy becomes "Do you care if the dome light in the car gets tested as long as the critical systems (brakes, headlights, transmission, etc) are tested". As a harried project sponsor that is seeing the project go past it's end date, I don't really care if the dome light gets tested or not.

Answer 5

You don't. Tests shouldn't be something that are written separately so there's no more need to account for them in the schedule than you would specifically schedule "compiling" or "typing in the code". Any time spent writing the tests should be offset by the time they save you anyway.

Answer 6

One good way to sell the value of unit tests is from a support standpoint -- if you are using a unit testing framework that has a runtime that can be deployed (nUnit is one), you can have a "Run Unit Tests" menu item on your help menu. This can run all of the unit tests, and the results can be sent to tech support to help debug client problems.

Obviously there are a lot of ways you could go about selling the increased stability, but tech support is a "real money" cost that most managers would want to lower.

Answer 7

Well I think the problem is you are say "all functions". All functions don't need unit tests, and some would argue that unit testing individual functions at all is down-right wrong in many scenarios.

Instead, I recommend unit testing actual "units of functionality". Instead of writing a single test for each function, write a test for each scenario or feature. Besides saving you lots of time and allowing you to slip in the tests in under the radar, it is often far more accurate because it literally tests the functions they way they are being used. Too often function by function unit tests don't test the right thing, or even worse, test mocks.

I recommend you avoid using mocks in testing at all costs. The use of a mock essentially invalidates the test because you are testing how it works in idealized circumstances instead of how it works in the real world.

A side benefit is that you also get better dead-code detection. Any code that isn't covered by a high level test probably isn't being used and can be removed. Never underestimate the value of eliminating dead code.

Answer 8

I just wrote at length about this very topic.

To summarize my arguments against the common complaints:

Clean-up is invisible to users; we need to add new features. The bugs constantly produced by messy code are visible to users too. Time spent fixing those bugs could have been spent adding features. The longer we stay in quality debt, the more time it takes to add each new feature.

We don't have time for clean-up. You'd rather spend your time fixing bugs generated by the problem rather than fixing the problem? That's like whacking weeds every weekend instead of pulling them up by the roots. Prevention is sixteen times more valuable than cure.

Developers got themselves into this mess; they should get themselves out of it on their own time. Had developers not gotten releases out the door as fast as they did, had they not responded so swiftly to early adopter feedback, even when the product morphed into a beast quite different from its original conception, we wouldn't have our current customers and revenue. We'd be working for another company, not complaining about the software we built.

Attention CEO's: Finger-pointing impedes resolution. Instead, challenge your developers to reduce bug reports. This is easily measured, so you can track time versus results. Remember, developers prefer implementing new features to fixing bugs, so if they're begging for time to fix bugs, it's serious.

Answer 9

Just do it. You will be slower in the beginning as you are writing more code and thinking out the problem first. But you will quickly pass others on the project as you have less errors/bugs and your design is better.

If you design the system with testing in mind, it will be inherently more flexible a design than a non-testable. It will then be quicker to add features to in the future.