8/6/2019 What Are Unit Testing
1/3
What are unit, component and integration testing?
The following definitions are from a posting by Boris Beizer
on
the topic of "integration testing" in the c.s.t. newsgroup.
The definitions of integration tests are after Leung and
White.
Note that the definitions of unit, component, integration,
and
integration testing are recursive:
Unit. The smallest compilable component. A unit typically is
the
work of one programmer (At least in principle). As defined, it
does
not include any called sub-components (for procedural languages)
or
communicating components in general.
Unit Testing: in unit testing called components (or
communicating
components) are replaced with stubs, simulators, or trusted
components. Calling components are replaced with drivers or
trusted
super-components. The unit is tested in isolation.
component: a unit is a component. The integration of one or
more
components is a component.
Note: The reason for "one or more" as contrasted to "Two or
more" is to allow for components that call themselves
recursively.
component testing: the same as unit testing except that all
stubs
and simulators are replaced with the real thing.
Two components (actually one or more) are said to be integrated
when:
a. They have been compiled, linked, and loaded together.
b. They have successfully passed the integration tests at
the
interface between them.
Thus, components A and B are integrated to create a new,
larger,
8/6/2019 What Are Unit Testing
2/3
component (A,B). Note that this does not conflict with the idea
of
incremental integration -- it just means that A is a big
component
and B, the component added, is a small one.
Integration testing: carrying out integration tests.
Integration tests (After Leung and White) for procedural
languages.
This is easily generalized for OO languages by using the
equivalent
constructs for message passing. In the following, the word
"call"
is to be understood in the most general sense of a data flow and
is
not restricted to just formal subroutine calls and returns --
for
example, passage of data through global data structures and/or
the
use of pointers.
Let A and B be two components in which A calls B.
Let Ta be the component level tests of A
Let Tb be the component level tests of B
Tab The tests in A's suite that cause A to call B.
Tbsa The tests in B's suite for which it is possible to
sensitize A
-- the inputs are to A, not B.
Tbsa + Tab == the integration test suite (+ = union).
Note: Sensitize is a technical term. It means inputs that
will
cause a routine to go down a specified path. The inputs are
to
A. Not every input to A will cause A to traverse a path in
which B is called. Tbsa is the set of tests which do cause A
to
follow a path in which B is called. The outcome of the test
of
B may or may not be affected.
There have been variations on these definitions, but the key
point is
that it is pretty darn formal and there's a goodly hunk of
testing
theory, especially as concerns integration testing, OO testing,
and
regression testing, based on them.
As to the difference between integration testing and system
testing.
System testing specifically goes after behaviors and bugs that
are
properties of the entire system as distinct from properties
attributable to components (unless, of course, the component
in
question is the entire system). Examples of system testing
issues:
