1.1 Important Terms

Now we (hopefully) agree that developer tests are indispensable for high-quality software. But, then, even developers test different things in different ways. For example, performance and load tests concentrate on the fulfillment of certain nonfunctional requirements, like required response times and the expected number of users. A programmer's central test tasks are, however, the so-called unit tests. This term originates from the preobject-oriented era and tells us that individual tests concentrate on single units of the system rather than on the entire system. Today, we also often speak of component tests.

Back then, it was pretty easy to recognize such a unit as a procedure or function. In object-oriented systems, this "unit to be tested" can take different shapes. The span reaches from a single method over a class and subsystem to the entire system. Mostly (but not always) this unit concerns the "natural" abstraction unit of an object-oriented system: the class or its instantiated form, the object. To avoid the somewhat clumsy phrase unit to be tested, I will also be using the terms class under test (CUT) and object under test (OUT) from the relevant literature in the further course of this book. The difference between the two terms lies in one's perspective: in the middle of a test, I'm interested in the object itself; when talking about several tests, then the class is my point of reference.

Developers also have to grapple with integration tests. These are tests concentrating on the interplay of several previously tested components. For this reason, McGregor [01] also calls these tests interaction tests. However, considering that, in object-oriented systems, each integration is also represented by one or more objects, it is often impossible to strictly separate between component tests and integration tests. We will deal with this issue wherever a differentiation appears meaningful in the further course of this book. However, we should generally not pay too much attention to this issue. What's important is the result of our test efforts and not a perfect terminological classification.

Unit tests are the central topic of this book, but it takes much more to achieve a high-quality software that is well accepted by the customer. For example, we distinguish between static and dynamic tests. Static tests can be applied without actually running the program and comprise such things as automated code analyzers as well as code inspections performed by other developers [Gilb93]. Dynamic tests require the code to be executed and are found again as functional tests, acceptance tests, regression tests, and other variants. Often, these tests are specified and conducted by a dedicated test team or even by the customers themselves. In this book, we will mainly focus on developer-side tests, until Chapter 14, where we describe the role of our unit tests from an overall view, i.e., software process and quality assurance.

To many testers and testing developers the key problem is, When are my tests adequate? When have I tested enough? In classic unit testing these questions are usually answered by the notion of test coverage: how much of the code and how much of the requirements specification is being covered by my tests? In that respect a suite of tests is considered adequate when it just covers everything; more tests would be a waste of effort. To decide what a term like full coverage means, numerous coverage metrics can be defined (see Chapter 8, Section 8.3, Test Coverage).