| You
are here: Freetutes.com
> Systems
Analysis and Design
Unit Testing
We know that smallest unit of software design is a module. Unit testing is performed
to check the functionality of these units. it is done before these modules are
integrated together to build the overall system. Since the modules are small in
size, individual programmers can do unit testing on their respective modules.
So unit testing is basically white box oriented. Procedural design descriptions
are used and control paths are tested to uncover errors within individual modules.
Unit testing can be done for more than one module at a time. The following
are the tests that are performed during the unit testing:
-
Module interface test: here it is checked if the information is properly flowing
into the program unit and properly coming out of it.
-
Local data structures: these are tested to see if the local data within unit(module)
is stored properly by them.
-
Boundary conditions: It is observed that much software often fails at boundary
conditions. That's why boundary conditions are tested to ensure that the program
is properly working at its boundary conditions.
-
Independent paths: All independent paths are tested to see that they are properly
executing their task and terminating at the end of the program.
-
Error handling paths: These are tested to check if errors are handled properly
by them.
See fig. 9.4 for overview of unit testing
Fig 9.4 Unit Testing
Unit Testing Procedure
Fig 9.5 Unit Test Procedure
Unit testing begins after the source code is developed, reviewed and verified
for the correct syntax. Here design documents help in making test cases. Though
each module performs a specific task yet it is not a standalone program. It may
need data from some other module or it may need to send some data or control information
to some other module. Since in unit testing each module is tested individually,
so the need to obtain data from other module or passing data to other module is
achieved by the use of stubs and drivers. Stubs and drivers are used to simulate
those modules. A driver is basically a program that accepts test case data and
passes that data to the module that is being tested. It also prints the relevant
results. Similarly stubs are also programs that are used to replace modules that
are subordinate to the module to be tested. It does minimal data manipulation,
prints verification of entry, and returns. Fig. 9.5 illustrates this unit test
procedure.
Drivers and stubs are overhead because they are developed but are not a part
of the product. This overhead can be reduced if these are kept very simple.
Once the individual modules are tested then these modules are integrated to
form the bigger program structures. So next stage of testing deals with the errors
that occur while integrating modules. That's why next testing done is called integration
testing, which is discussed next.
<<
Previous Page | Contents
| Next Page >>
|
