To many, unit testing is a foreign concept. This is understandable as it is a topic which is poorly taught in many schools. I know that I've done six years of higher education in computing science without it being mentioned. It is unfortunate because delivering a quality product is a pretty important part of any project.

For those who know about unit testing, there is a big barrier to adoption. Managers, and even developers, frequently see unit testing, and automated testing as a whole, as a waste of time. After all you cannot ship a unit test to your customer nor do most customers care whether their product has been properly unit tested.

Unit testing is notoriously difficult to define. It is close enough to integration testing that people slip back and forth between the two easily. In the seminal book; The Art of Unit Testing, Roy Osherove, the author defines a unit test as:

The exact size of a unit of work is up for some debate. Some people restrict it to a single function or a single class, while others allow a unit of work to span multiple classes. I tend to think that a unit of work that spans multiple classes can actually be broken into smaller, testable units.

The key to unit testing is that it tests a small piece of functionality and it quickly tests the functionality in a repeatable, automated fashion. Unit tests written by one person should be easily runnable by any other member of the team.

For unit testing we want to test small pieces of functionality because we believe that if all the components of a system work correctly then the system as a whole will work. This is not the whole truth. The communication between modules is just as likely to fail as a function within the unit. This is why we want to write tests on several levels. Unit tests check that the code we're writing right now is correct. Integration testing tests entire workflows through the application and will uncover problems in the interaction of units.

The test-driven development approach suggests writing tests at the same time as we write code. While this gives us great confidence that the code we're writing is correct, the real advantage is that it helps drive good architecture. When code has too many interdependencies it is far harder to test than well-separated modular code. A lot of the code that developers write goes unread by anybody ever again. Unit tests provide a useful way of keeping developers on the right path even in cases where they know that nobody will ever see their code. There is no better way to produce a quality product than to tell people they are going to be checked on it, even if the checker happens to be an automated test.

Tests can be run both while developing new code and in an automatic fashion on the build machines. If every time a developer checks in a change, the entire project is built and tested, then some reassurance can be provided that the newly checked-in code is correct. From time to time the build will break and that will be a flag that something that was just added was in error. Often the code that is broken may not even be proximal to the code changed. An altered return value may percolate through the system and manifest itself somewhere wholly unexpected. Nobody can keep anything more than the most trivial system in their mind at any one time. Testing acts as a sort of second memory, checking and rechecking assumptions made previously.

Failing the build as soon as an error occurs shortens the time it takes between an error being made in the code and it being found and fixed. Ideally the problem will still be fresh in the developer's mind so the fix can easily be found. If the errors were not discovered until months down the road, the developer will certainly have forgotten what s/he was working on at the time. The developer may not even be around to help solve the problem, throwing somebody who has never seen the code in to fix it.