How much unit testing is a good thing? [closed]

Question

(No "related questions" seem to nail this, so here goes.)

I work on production code. Arguing for anything that isn't visible to the user is hard to do, sometimes. If sales can't see it, it's an external cost to them, and they'll argue against it unless there's a great reason not to.

How much unit testing is a good thing? If you test every class, every method, your current release will take longer, possibly much longer. If you test nothing, maintenance in the future will take you longer, possibly much longer as bugfixes and new functionality cause problems you didn't foresee, and that the unit tests would have caught.

How do you find a healthy, justifiable balance?

Edit: to answer a few questions that people reasonable have raised...

1. Sales isn't running the process, but they certainly have input, and should have limited input in any group. They're the ones who pay the bills. If they're completely steering everything, that would be unreasonable, obviously.

2. I'm certain there's no best answer, but I'm curious as to what other people think is reasonable. I'm expecting both extremes (everything! nothing!), and a lot in the middle.

3. No one gets to choose their manager, and if a bad policy on unit testing is a make-or-break decision in someone staying with a company/project... you have a lot more career options than most of us, friend. :-)

Second Edit: "Justifiable" is an important word in there. If I want to have time budgeted/allowed for unit testing, and don't want to have to sneak it in, I'm going to need to justify the why. The top answer right now, for me, is "test things that have broken before", because I can always justify reactive policies.

Any ideas on how to justify something proactive?

Answer 1

Two suggestions for minimal unit testing that will provide the most "bang for the buck":

Start by profiling your application to find the most commonly used parts - make sure those are unit tested. Keep moving outward to the less commonly used code.

When a bug is fixed, write a unit test that would have detected it.

Answer 2

This, I think, is a fallacy:

If you test every class, every method, your current release will take longer, possibly much longer.

Testing - especially Test First - improves our flow, keeps us in the zone, actually speeds us up. I get work done faster, because I test. It is failing to test that slows us down.

I don't test getters and setters; I think that's pointless - especially since they're auto-generated. But pretty much everything else - that's my practice and my advice.

Answer 3

Start creating unit tests for the most problematic areas (ie sections of code that often breaks and causes a lot of communication between the sales team and developers). This will cause an immediate and visible impact by the sales team and other personnel.

Then once you have credibility and they see the value, start adding less problematic areas until you start to notice that the ROI just isn't there anymore.

Sure full coverage is nice in theory, but in practice it's often not necessary. Not to mention too costly.