Over the years, many different and mutually exclusive definitions of the term unit test have arisen. Many people say “unit test” when they really mean component test, integration test, or even user acceptance test (UAT). This can lead to a lot of confusion in software development in general. In TDD that confusion takes on a whole new dimension when you consider just how central to the practice of TDD unit tests are. It's important for the sake of communicating with our fellow developers that we maintain a consistent definition of the term “unit test.”

Unit Test Definition

In the simplest terms, a unit test is a test designed to test one unit of work. In this case “one unit of work” means one requirement for one method. The example from Chapter 1 tested an algorithm to count the number of occurrences of a given character in a given string. You didn't know where the string or character came from; that detail was unimportant to the given unit of work, which was counting the occurrences of the character in the string. Everything else was out of scope for the unit of work.

The benefit of this type of test is the fact that it is confined to only one specific unit of work. You can focus your efforts on your unit of work. You don't need to know the details of the other players in the system (unless you have a direct dependency on them). This makes writing the tests, and the resulting code, easier. Additionally, if a defect does appear in your code that causes your ...

Get Professional Test-Driven Development with C#: Developing Real World Applications with TDD now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.