Guidelines: Unit Test
Topics
Unit testing is implemented against the smallest testable element (units) of
the software, and involves testing the internal structure such as logic and
data flow, and the unit's function and observable behaviors. Designing and implementing
tests focused on a unit's internal structure rely upon the knowledge of the
unit's implementation (white-box approach). The design and implementation of
tests to verify the unit's observable behaviors and functions do not rely upon
a knowledge of the implementation and therefore is known as black-box approach.
Both approaches are used to design and implement the different types of tests
(see
Concepts: Type of Tests ) needed
to successfully and completely test units.
See also Guidelines: Test Case for additional
information on deriving test cases for unit test.
A white-box test approach should be
taken to verify a unit's internal structure. Theoretically, you should test
every possible path through the code, but that is possible only in very simple
units. At the very least you should exercise every decision-to-decision
path (DD-path) at least once because you are then executing all
statements at least once. A decision is typically an if-statement, and a DD-path
is a path between two decisions.
To get this level of test coverage, it is recommended that you choose test
data so that every decision is evaluated in every possible way.
Use code-coverage tools to identify the code not exercised by your white box
testing. Reliability testing should be done simultaneously with your white-box
testing.
See Guidelines: Test Case for additional
information
The purpose of a black-box test is to verify the unit's specified function
and observable behavior without knowledge of how the unit
implements the function and behavior. Black-box tests focus and rely upon the
unit's input and output.
Deriving unit tests based upon the black-box approach utilizes the input and
output arguments of the unit's operations, and / or output state for evaluation.
For example, the operation may include an algorithm (requiring two values as
input and return a third as output), or initiate change in an object's or
component's state, such as adding or deleting a database record. Both must
be tested completely. To test an operation, you should derive sufficient test
cases to verify the following:
- for each valid value used as input, an appropriate value was returned by
the operation
- for each invalid value used as input, only an appropriate value was returned
by the operation
- for each valid input state, an appropriate output state occurs
- for each invalid input state, an appropriate output state occurs
Use code-coverage tools to identify the code not exercised by your white box
testing. Reliability testing should be done simultaneously with your black-box
testing.
See Guidelines: Test Case for additional
information
|