When we consider testing to be essential, testability is an important design consideration for object-oriented programming. Our designs must also support testing and debugging, because a class that merely appears to work is of no value. A class that has evidence that it works is much more valuable.

Different types of tests form a kind of hierarchy. At the foundation of that hierarchy is unit testing. Here, we test each class or function in isolation to be sure that it meets the contractual obligations of the API. Each class or function is an isolated unit under test. Above this layer comes integration testing. Once we know that each class and function works individually, we can test groups and clusters of classes. We can test whole modules and whole packages too. Once the integration tests work, the next layer is the automated testing of the complete application. This is not an exhaustive list of the types of tests. We can do performance testing and security vulnerability testing too.

In this chapter, we'll focus on automated unit testing because it is central to all applications. The hierarchy of testing reveals important complexity. Test cases for an individual class or group of classes can be very narrowly defined. As we introduce more units into integration testing, the domain of inputs grows. When we attempt to test a whole application, the entire spectrum of human behavior becomes potential input. As we look more broadly, we see that it could include shutting devices off, pulling out plugs, or even pushing devices off tables to see whether they still work after being dropped three feet onto a hardwood floor. The hugeness of the domain of human behavior makes it difficult to fully automate all possible kinds of application testing. We'll focus on the things that are easiest to test automatically. Once the unit tests work, the larger aggregate systems are more likely to work.