Check list for Conducting Unit Tests


§ Is the number of input parameters equal to number of arguments?
§ Do parameter and argument attributes match?
§ Do parameter and argument units system match?
§ Is the number of arguments transmitted to called modules equal to number of parameters?
§ Are the attributes of arguments transmitted to called modules equal to attributes of parameters?
§ Is the units system of arguments transmitted to called modules equal to units system of parameters?
§ Are the number of attributes and the order of arguments to built-in functions correct?
§ Are any references to parameters not associated with current point of entry?
§ Have input only arguments altered?
§ Are global variable definitions consistent across modules?
§ Are constraints passed as arguments?
§ When a module performs external I/O, additional interface tests must be conducted.

Again, from Myers:
§ File attributes correct?
§ OPEN/CLOSE statements correct?
§ Format specification matches I/O statement?
§ Buffer size matches record size?
§ Files opened before use?
§ End-of-file conditions handled?
§ I/O errors handled?
§ Any textual errors in output information?
The local data structure for a module is a common source of errors. Test cases should be designed to uncover errors in the following categories:
§ improper or inconsistent typing
§ erroneous initialization or default values
§ incorrect (misspelled or truncated) variable names
§ inconsistent data types
§ underflow, overflow and addressing exceptions
From a strategic point of view, the following questions should be addressed:
§ Has the component interface been fully tested?
§ Have local data structured been exercised at their boundaries?
§ Has the cyclomatic complexity of the module been determined?
§ Have all independent basis paths been tested?
§ Have all loops been tested appropriately?
§ Have data flow paths been tested?
§ Have all error handling paths been tested?