Integration tests

Integration tests

Integration test for procedural code has two major goals:

(i) to detect defects that occur on the interfaces of units;

(ii) to assemble the individual units into working subsystems and finally a complete system that is ready for system test.

In unit test the testers attempt to detect defects that are related to the functionality and structure of the unit. There is some simple testing of unit interfaces when the units interact with drivers and stubs. However, the interfaces are more adequately tested during integration test when each unit is finally connected to a full and working implementation of those units it calls, and those that call it. As a consequence of this assembly or integration process, software subsystems and finally a completed system is put together during the integration test. The completed system is then ready for system testing.

With a few minor exceptions, integration test should only be performed on units that have been reviewed and have successfully passed unit testing. A tester might believe erroneously that since a unit has already been tested during a unit test with a driver and stubs, it does not need to be retested in combination with other units during integration test. However, a unit tested in isolation may not have been tested adequately for the situation where it is combined with other modules. This is also a consequences of one of the testing axioms found in Chapter 4 called anticomposition.

Integration testing works best as an iterative process in proceduraloriented system. One unit at a time is integrated into a set of previously integrated modules which have passed a set of integration tests. The interfaces and functionally of the new unit in combination with the previously integrated units is tested. When a subsystem is built from units integrated in this stepwise manner, then performance, security, and stress tests can be performed on this subsystem.

Integrating one unit at a time helps the testers in several ways. It keeps the number of new interfaces to be examined small, so tests can focus on these interfaces only. Experienced testers know that many defects occur at module interfaces. Another advantage is that the massive failures that often occur when multiple units are integrated at once is avoided. This approach also helps the developers; it allows defect search and repair to be confined to a small known number of components and interfaces. Independent subsystems can be integrated in parallel as long as the required units are available. The integration process in object-oriented systems is driven by assembly of the classes into cooperating groups. The cooperating groups of classes are tested as a whole and then combined into higher-level groups. Usually the simpler groups are tested first, and then combined to form higher-level groups until the system is assembled.