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

Answer 1

Companies are not performing unit testing, for the same reason that many websites are written poorly – ignorance, and people sticking to old habits. At my company, since we started unit testing (with Nunit, and Typemock), we reach higher code coverage and release the software in a shorter time to market.

Answer 2

I'm a huge fan of unit tests and I also am a partner in a company doing contract development projects for various client types. In a month we'll touch 3-4 different projects of varying sizes.

If a project seems like it's going to be a one off, I'm not going to invest heavily in unit testing because that unit testing doesn't pay off for my business. On those types of projects I'm going to unit test things that I'm uncertain/unfamiliar with or that could change frequently (such as a parser for a data source I don't control.)

Whereas if I'm building something that I know is going to have a long life time, is a larger piece of work, that I'll be working with through multiple iterations, or will have a large impact on my clients if an error occurs, I'm going to invest in more unit testing. Again priority of tests revolves around uncertain/unfamiliar/changing code.

I think unit tests ought to revolve around the complexity of a task, as well as whether they're going to pay off. There's no sense in writing extra code that isn't going to get used.

Answer 3

My 2 cents:

• It requires some education and discipline, but new graduates already come with the proper knowledge.
• Tests overhead can be reduced with better tools and this is happening also (refactoring etc.)

So, it's just a matter of time.

There's the Martin-Coplien debate in which Bob Martin asserts that:

"nowadays it is irresponsible for a developer to ship a line of code he has not executed in a unit test."

[http://www.infoq.com/interviews/coplien-martin-tdd]

Answer 4

Aside from the issue of adoption of unit testing, unit testing isn't always worthwhile, though in general I think it is, when applied properly. There is nothing special about unit tests that saves them from being vulnerable to poor construction.

Unit tests have costs (creation, maintenance, and running) and are only worthwhile if they provide greater benefits than those costs. Test creation is a skill like any other, it requires specific experience and knowledge for success. Without sufficient experience it's very easy for even otherwise experienced developers to create low quality, low value, and/or high cost unit tests which are not worthwhile. Especially so given how difficult it can be to judge the value of a unit test.

Additionally, unit testing is just one way to improve code quality, but it's not the only way. In some circumstances and with some teams it may not be the most effective way to increase the quality of software.

Keep in mind that putting a lot of effort into unit testing is no guarantee of quality software. And, too, it is possible to produce software of the highest quality without any unit testing whatsoever.

Answer 5

I think that the programmer has to just start doing it. A few simple tests to start with are easy to justify as part of development.

Something like a unit test is almost always necessary to get fast debugging turn around. Just explain how much faster it is to launch the test than it is to arrange the correct input, set a debugger breakpoint, launch the application, etc.

Document the test in your code. Just put a comment explaining where the test is and how to run it. Future programmers will see it and hopefully the testing will spread!

Answer 6

I don't think laziness is the root cause of bad unit testing. For my company, time constraints and "just get it done" attitude are the biggest deterrents for doing unit testing. Also, the places where our systems fail tend to be more at the integration level (services, database accesses, complex queries that require specific data for testing), not the "unit level." These things are just harder to test, and if you barely have enough time to get the feature done, you're probably not going to have time to get any useful tests done at the same time.