Unit Test Checklist

Sponsored Links:

• Is the number of input parameters equal to the number of arguments?
• What parameters and argument attributes match?
• Are the parameters and units agree with the argument of the system?
• Is the number of arguments passed to called modules equal to the number of parameters?
• Are the attributes of the arguments passed to called modules equal to the attributes of the parameters?
• Is the system of units of the arguments passed to called modules equal to the units of the system parameters?
• The number of attributes and the order of the arguments of built-in functions right?
• Are there references to parameters not related to the current entry point?
• Have input arguments only altered?
• Are global variable definitions consistent across modules?
• Restrictions are passed as arguments?

When performing an external module I / S, further tests of interface must be implemented:
• 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 error in the output text information?
The local data structure for a module is a common source of errors. The test cases should be designed for detecting errors in the following categories:
• Inadequate or inconsistent writing
• incorrect initialization or default values
• incorrect (misspelled or truncated) variable names
• types of inconsistent data
• Underflow, overflow and addressing exceptions
From a strategic standpoint, the following questions should be addressed:
• component interface has been fully tested?
• Have structured local data has exercised its borders?
• Has the cyclomatic complexity of the module has been determined?
• Have all paths independently tested?
• Have all loops been adequately tested?
• Have the data flow paths tested? Make all routes handling errors has proved?