Unit testing focuses verification effort on the smallest unit of software design – the software component or module. Using the component level design as a guide, important control paths are tested to uncover errors within the boundary of the module. The relative complexity of tests and uncovered errors is limited by the constrained scope established for unit testing. The unit test is White Box oriented and the step can be conducted in parallel for multiple components. Unit Test Considerations:
– Module interface is tested to ensure that all information properly flows into and out of the program unit under test. – Local data structure is examined to ensure that data stored temporarily maintains its integrity during all steps in an algorithm’s execution. – Boundary conditions are tested to ensure that the module operates properly at boundaries established to limit or restrict processing. – All independent paths (basis paths) through the control structure are exercised to ensure that all statements in a module have been executed at least once. – And finally, all error handling paths are tested.
– Tests of data flow across a module interface are required before any other test is initiated. If data do not enter and exit properly, all other tests are moot. – In addition, local data structures should be exercised and the local impact on global data should be ascertained (if possible) during unit testing. – Selective testing of execution paths is an essential task during unit test. Testcases should be designed to uncover errors due to erroneous computations, incorrect comparisons, or improper control flow. Basis path and loop testing are effective techniques for uncovering a broad array of path errors. – More common errors in computations are: § Misunderstood or incorrect arithmetic precedence. § Mixed mode operations. § Incorrect initialization. § Precision inaccuracy. § Incorrect symbolic representation of an expression.