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

Question

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.

1) It's hard
2) It takes time
3) It's very hard to determine the value of test code

Point 3 is a sticky one. Good unit tests reduce bugs. But so does good production code. How do you determine how many bugs don't exist because of your unit tests? You can't measure what does not exist. You can point to studies, but they don't fit nicely on your business manager's spreadsheet.

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.

Most tests don't test anything.
You write a fileopen() function and a unittest that fails if the file doesn't exist and succeeds if the file does exist. Great! Now did you check if it works with the filename in BIG5 chinese? on an NFS share? on vista with the file on a USB key and UAC turned ON?

The problem is that the unit tests are written by the same programmer who wrote the function, to the same set of assumptions and with the same level of skill. To really work the tests must be written by someone else, only to the published specs without them seeing the code. - In most companies just getting written specs would be a breakthrough!

Unit tests check for errors in the code of individual functions. They can work for data access layers, maths libraries etc where the inputs/outputs are well known and the internal structure is complex but for a lot of cases they are just a waste of time.
They fail when the errors are due to interactions between different parts of code or with the OS and the user. Problems like high/low DPI settings messing up a dialog box or a foreign language setting swapping a '.' and ',' aren't usually found.

There have been studies done on the ROI of unit tests - see this question.