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

Answer 1

I've found a lot of developers who aren't interested in unit testing. It always seems like a lot of work with little payoff when you start. No one wants to sign up for extra work and so they resist. Once people start, they usually enthusiastically stick with it, but getting them started can be hard.

Answer 2

Well, my company hasn't gone with TDD or Unit Testing. To be honest, we're not sure how to do it. We can obviously do it for stupid functions like CapitalizeString(), etc, but we don't know how to do it for highly complex systems with complicated objects. Moreover, most of the people interviewed have either zero experience, or limited experience. It appears that Unit Testing is big from the SO crowd, but not particularly big in the available workpool.

TDD is a separate topic. We are morally opposed to TDD. We aren't cowboy coders, but we do believe that it stunts creativity and flexibility in a project. Moreover, having the coder who wrote the unit testing function makes no sense. When I do something, I code to all of the edge cases I can think of. What I need is another brain to look for things I might have missed. We don't have that. The teams are small and self-contained.

In short, we don't believe in TDD, but we would like to Unit Test. We just don't have the experience to do so, and we can't find it easily.

Answer 3

People are lazy and only adopt change when forced to.

Answer 4

Like most good ideas, adoption has more to do with organizational path dependence than with the quality of idea.

In most companies that have shipped products, a substantial QA division has been created with a senior level QA head. Testing is the fiefdom of the QA team.

The QA team is unlikely to write unit test code because the company typically doesn't staff the QA team with its heavy duty coders.

The programming team is reluctant to write test code because it creates a conflict with the QA team.

I've been seeing more interest and adoption of Unit Testing in groups where QA hasn't been spun off into a separate job function

Answer 5

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.

Answer 6

In my experience it really depends on the software you are writing. I have found it is extremely hard to write unit tests for a UI. I only use unit tests for portions of the system that have a definite in/out.