The other issue was annoyance over evangelism, which is at the core of much of the agile movement (which began with a signed manifesto and a formulated creed). "Please, please, please, no more evangelism!!" wrote Gabriel C. A segment of the agile development community has adopted unit testing in a radical way, insisting that tests be written before the code.
This approach, called test-driven development, is intended to clarify design before committing to code. Its proponents have been zealous in promoting test-driven development as the best way to program, but for many developers that evangelism has become so overbearing that it makes unit testing as a whole unappealing.
Why you should give unit testing a second look
Unfortunately, these reasons conspire to obscure the benefits of unit testing, so it is frequently rejected at sites in favor of traditional testing, rather than being viewed as an important adjunct to it. That's a mistake. Unit testing has four significant benefits that, in my experience, all organizations that adopt it recognize almost immediately: Defects are identified nearly immediately, and because unit testing isolates their cause and effect, they are also resolved more quickly. As a result, you can be more confident in the schedule. You also get better code-level documentation.
But the principal result of unit testing is better code. In the traditional manner of development, code is written and quickly checked by the developer against a narrow set of criteria. Once it works, the developer moves on to other coding. Whether that routine works later on is a question that the developer faces only when examining the larger software package or during the testing cycle. At that point, the developer might easily spend hours with a debugger figuring out why the routine is unexpectedly balking.
These long debug sessions are terribly expensive to projects on several levels. As there is no method for predicting how long it will take to locate and resolve a bug, nor what effects that bug fix will have, there is no way to accurately project schedules.
Compare this to the unit testing approach in which the writing and constant running of tests immediately identifies a routine that is not working. Because of this immediacy, the developer can be essentially certain that the most recent change is the cause of a newly discovered defect. Thus, cause and effect are tightly mapped, and the code can be fixed immediately, without long hours in the debugger trying to find the fault. Moreover, when a bug is fixed, the developer can run the entire set of unit tests to make sure no other routines are now failing due to the previous fix.
Another result of unit testing is increased confidence in the code. Under traditional testing, with each extensive debugging session, confidence in the code tends to diminish. After several such sessions, the manager has no real way of knowing whether the major bugs have been found, nor how many more debugging sessions are in store. So the final result is delivered with the hope, rather than the conviction, that it works correctly.
Unit testing ensures that defects are resolved as coding progresses, making the project schedule easier to gauge, and allowing you to more accurately project completion dates. And because unit tests capture how the developer expects a given unit to be used -- as well as what untoward data or events it might encounter that need to be accounted for -- you get better documentation.