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.
No comments:
Post a Comment