Integration tests for procedural software can be designed using a black or white box approach. Both are recommended. Some unit tests can be
reused. Since many errors occur at module interfaces, test designers need to focus on exercising all input/output parameter pairs, and all calling
relationships. The tester needs to insure the parameters are of the correct type and in the correct order. The author has had the personal experience
of spending many hours trying to locate a fault that was due to an incorrect ordering of parameters in the calling routine. The tester must also
insure that once the parameters are passed to a routine they are used correctly. For example, in Figure 6.9, Procedure_b is being integrated with
Procedure_a. Procedure_a calls Procedure_b with two input parameters in3, in4. Procedure_b uses those parameters and then returns a value for
the output parameter out1. Terms such as lhs and rhs could be any vari- able or expression. The reader should interpret the use of the variables in
the broadest sense. The parameters could be involved in a number of def and/or use data flow patterns. The actual usage patterns of the parameters
must be checked at integration time. Data flow–based (def-use paths) and control flow (branch coverage) test data generation methods are useful
here to insure that the input parameters, in3, in4, are used properly in Procedure_b. Again data flow methods (def-use pairs) could also be used
to check that the proper sequence of data flow operations is being carried out to generate the correct value for out1 that flows back to Procedure_a.
Black box tests are useful in this example for checking the behavior of the pair of procedures. For this example test input values for the input
parameters in1 and in2 should be provided, and the outcome in out2 should be examined for correctness.