This article is taken from the book The Art of Unit Testing. As part of a chapter on integrating unit testing into your current organization, this segment answers one of the key questions involving unit testing.

Author: Roy Osherove

This article is based on The Art of Unit Testing, to be published in January 2009. It is being reproduced here by permission from Manning Publications. Manning early access books and ebooks are sold exclusively through Manning. Visit the book’s page for more information.

Let’s begin with some facts. Studies have shown that raising the code quality overall in the project can increase productivity and shorten schedules (Capers, Programming Productivity 1986) (Capers, Software assesments, benchmarks and best practices 2000). How does this sit with the fact that writing tests can take longer to code? Maintainability and ease of fixing bugs, mostly.

This question is usually asked by the people who are in the front lines in terms of timing. Team leads, project managers and clients.  There is a difference in views here. A team lead may really be asking “So what should I tell my project manager when we go way past our due date?” but they may think the process is useful, they are just looking for ammo in the upcoming uphill battle. They may also be asking the question not in terms of the whole product, but in terms of specific feature sets or functionality. A project manager or customer, on the other hand, will usually be talking in terms of full product releases.

The fact that different people may care about different scopes is relevant because the answer for specific scopes may be different. For example, unit testing can even double the time it takes to implement a specific feature in the next month, but the overall bottom line release date for the product in the next five months may actually be sooner. To understand this, let’s look at a real example from a company I was involved with.