Object-Oriented Design - Java Software Solutions: Foundations of Program Design - page 347

reliability of our program by finding and fixing the errors that exist,
rather than letting users discover them.
A test case consists of a set of inputs, user actions, or other initial
conditions, along with the expected output. A test case should be
appropriately documented so that it can be repeated later as needed.
Developers often create a complete test suite, which is a set of test cases that cov-
ers various aspects of the system.
Because programs operate on a large number of possible inputs,
it is not feasible to create test cases for all possible input or user
actions. Nor is it usually necessary to test every single situation.
Two specific test cases may be so similar that they actually do not
test unique aspects of the program. To do both would be a wasted
effort. We'd rather execute a test case that stresses the program in
some new way. Therefore we want to choose our test cases carefully. To that end,
let's examine two approaches to defect testing: black-box testing and white-box
testing.
As the name implies, black-box testing treats the thing being tested as a black
box. In black-box testing, test cases are developed without regard to the internal
workings. Black-box tests are based on inputs and outputs. An entire program
can be tested using a black-box technique, in which case the inputs are the user-
provided information and user actions such as button pushes. A test case is suc-
cessful only if the input produces the expected output. A single class can also be
tested using a black-box technique, which focuses on the system interface (its
public methods) of the class. Certain parameters are passed in, producing certain
results. Black-box test cases are often derived directly from the requirements of
the system or from the stated purpose of a method.
The input data for a black-box test case are often selected by defining
equivalence categories. An equivalence category is a collection of inputs that are
expected to produce similar outputs. Generally, if a method will work for one
value in the equivalence category, we have every reason to believe it will work for
the others. For example, the input to a method that computes the square root of
an integer can be divided into two equivalence categories: nonnegative integers
and negative integers. If it works appropriately for one nonnegative value, it will
likely work for all nonnegative values. Likewise, if it works appropriately for one
negative value, it will likely work for all negative values.
Equivalence categories have defined boundaries. Because all values of an equiv-
alence category essentially test the same features of a program, only one test case
inside the equivalence boundary is needed. However, because programming often
produces “off by one” errors, the values on and around the boundary should be
tested exhaustively. For an integer boundary, a good test suite would include at
least the exact value of the boundary, the boundary minus 1, and the boundary

KEY CONCEPT
A good test is one that uncovers an
error.

KEY CONCEPT
It is not feasible to exhaustively test
a program for all possible input and
user actions.