5.1. Test-Case Design

You need two types of information when designing test cases for a module test: a specification for the module and the module's source code. The specification typically defines the module's input and output parameters and its function.

Module testing is largely white-box oriented. One reason is that as you test larger entities such as entire programs (which will be the case for subsequent testing processes), white-box testing becomes less feasible. A second reason is that the subsequent testing processes are oriented toward finding different types of errors (for example, errors not necessarily associated with the program's logic, such as the program's failing to meet its users' requirements). Hence, the test-case-design procedure for a module test is the following: Analyze the module's logic using one or more of the white-box methods, and then supplement these test cases by applying black-box methods to the module's specification.

Since the test-case-design methods to be used have already been defined in Chapter 4, their use in a module test is illustrated here through an example. Assume that we wish to test a module named BONUS, and its function is to add $2,000 to the salary of all employees in the department or departments having the largest sales amount. However, if an eligible employee's current salary is $150,000 or more, or if the employee is a manager, the salary is increased by only $1,000.

The inputs to the module are the tables shown in Figure 5.1 ...

Get The Art of Software Testing, Second Edition now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.