If unit testing is so great, why aren't more companies doing it? [closed]

Answer 1

Its probably a combination of a couple of things you mentioned already. Its difficult to measure cost savings of TDD. If you want to outsource your IT, you can show how much you pay per year for the guys you have on staff vs. the cost of contracting it out; its very concrete. How do you say, "Oh, this test caught a bug which would have taken me 4 hours to debug and fix..."?

Answer 2

It is easy to put all the blame on “management.” But is management really telling you to specifically not do any unit testing?

Management in general does not (and probably should not) tell you how to do your job, whether it is modularization, abstract data types, design patterns, or unit testing. These are tools of trade that a successful, competent software engineer applies, but a poor engineer does not.

I think the real answer to your question is: unit testing is really difficult, and computer-science students are not trained for it.

It's easy when you are writing your own string class. When you are testing a real-life product, you run into challenges that nobody told you about in the powerpoint slides:

• User interaction. Half of your application is the user interface logic. How do you test it in an automated way, that doesn't break down if you move a button?
• Interaction with external APIs and frameworks. If you are writing a Windows kernel driver, how do you unit test it? Do you write stubs for every IRP and kernel function that you use, effectively creating a simulation of the OS kernel?
• Network communications is the thing of the 21st century. How do you coordinate a unit test consisting of several distributed components?
• How do you choose good test cases? I commonly see people trying the “do random things in a loop of 1000 iterations and see if it breaks” approach. When you do this the effort is higher than the returns, important bugs are missed, and unit testing is abandoned.
• How do you test that performance requirements are met?
• Knowledge of patterns in testing is scarce: stubs, canned responses, regression testing are concepts most people don't know. How many in your work place actually read a book about unit testing?

The one thing that we can blame management for is that requirement specifications rarely contain any requirements on quality level of the deliverable.

The next time your boss asks you to do a time estimate, include the time for writing a unit test and see what happens.

Answer 3

In my experience, there are a couple of factors involved in this:

1. Management doesn't really understand what unit testing really is, or why it has real intrinsic value to them.
2. Management tends to be more concerned with rapid product delivery, and (incorrectly) sees unit testing as counterproductive to that goal.
3. There's a misperception that testing belongs solely in the pervue of QA. Developers are coders, and can't write tests.
4. There's a common misperception that management will have to spend money to do unit testing correctly, despite the fact that the tools are freely available. (There is, of course, the developer ramp up time to consider, but it's not really prohibitive.)
5. Will's answer will round this answer out: It's very hard to determine the value of test code (edit jcollum)

Naturally, there are other factors, but those are just what I've run into so far.

Answer 4

From what I've seen, a lot of companies have huge, highly-coupled code bases that aren't practically unit testable. They also don't have decent testable requirements, so the unit tests would test against "as built" de facto requirements.

Answer 5

The reason some places don't use it is simply because it takes a lot of work both to get started and to continue. The fact that writing unit tests takes about as much time as writing the actual functionality seems to some managers like you're cutting your developer's productivity in half.

On top of that, you build team (or someone) needs to put the infrastructure in place and maintain it.

And as Alan says, a lot of places simply don't use best practices - they just want to see something tangible.

Answer 6

Of course, in the ideal world, you can not argue against having a unit test.

However, whether you write a unit test depends on a number of things:

• How the software will be used. If you were writing software for just yourself would you write unit tests? Probably not. If you were writing pre-packaged software to be sold commercially, probably yes.

• How many people maintain the code....if it's just you, then you may know it well enough to be confident enough after making a change that a quick run through of the code is sufficient to ensure nothing has broken. If other people who did not originally write the code must now maintain it then a unit test will help give them confidence that when they update the code to fix a big (that was obviously not captured in the unit test!) they have not broken anything.

• code complexity: only test code which needs a test. A one line variable assignment method does not need testing. A 50 line method with multiple paths of execution probably does.

• Practical commercial commercial considerations: The fact is writing unit tests does take longer than not doing so. If you are writing prototype software, that has an uncertain commercial future, then there is a pay off to be has between having code quickly, now, that works sufficiently well versus having unit tested code in 2 weeks that works better. Sometimes it pays to find out quickly (consumer appetite) if software will have a short shelf like and move on to the next project.

and as others have pointed out, a test is only as good as the person that wrote it.