Pragmatic Software Testing: Becoming an Effective and Efficient Test Professional

Chapter 25. Integration Testing

In this chapter, I cover some techniques for white-box integration testing of builds. By builds, I mean the sequence of integrated sets of communicating, interoperating, or interdependent units that make up part or all of the system under test. The sequence of these builds is usually driven by the architecture and also, ideally, by the risks posed to the system itself by failures that may occur in interactions between some set of units. I also discuss factors that influence the number of units you add in each build on your way toward integrating the entire system under test.

As with unit testing, integration testing is about saving money and controlling risk. Many bugs are errors in interactions between units. These interactions may occur through data, control flows, or communications between units. Two or more units that pass their unit tests may nevertheless exhibit bugs when they must work together.

A classic example of this occurred with one of the United States Mars missions in the late 1990s, which I mentioned in the earlier chapter on reviews. In that mission, the craft survived its entire trip to Mars only to crash into the surface. It turned out that one subsystem involved in the process of decelerating on landing performed its calculations in metric units. Another subsystem used English units. The result, understandably, was catastrophic. While the NASA team could have detected this bug through design, or code reviews, the earliest opportunity ...