Unit testing deals with testing a unit
as a whole. This would test the interaction of many
functions but confine the test within one unit. The exact scope of a
unit is left to interpretation. Supporting test code, sometimes called scaffolding,
may be necessary to support an individual test. This type of testing is driven by the architecture and implementation teams.
This focus is also called black-box testing because only the details of the interface are visible to the test. Limits
that are global to a unit are tested here.
In the construction industry, scaffolding is a temporary, easy to
assemble and disassemble, frame placed around a building to facilitate
the construction of the building. The construction workers first build
the scaffolding and then the building. Later the scaffolding is
removed, exposing the completed building. Similarly, in software
testing, one particular test may need some supporting software. This
software establishes an environment around the test. Only when this
environment is established can a correct evaluation of the test take
place. The scaffolding software
may establish state and values for data structures as well as providing
dummy external functions for the test. Different scaffolding software
may be needed from one test to another test. Scaffolding software
rarely is considered part of the system.
Sometimes the scaffolding software becomes larger than the system
software being tested. Usually the scaffolding software is not of the
same quality as the system software and frequently is quite fragile. A
small change in the test may lead to much larger changes in the
scaffolding.
Internal and unit testing can be automated with the help of coverage tools.
A coverage tool analyzes the source code and generates a test that will
execute every alternative thread of execution. It is still up to the
programmer to combine these test into meaningful cases to validate
the result of each thread of execution. Typically, the coverage tool
is used in a slightly different way. First the coverage tool is used to
augment the source by placing informational prints after
each line of code. Then the testing suite is executed generating
an audit trail. This audit trail is analyzed and reports the percent of
the total system code executed during the test suite. If the coverage is
high and the untested source lines are of low impact to the
system's overall quality, then no more additional tests are required.