Unit test checklist

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?