Unit testing

The purpose of conducting the unit test is to find any errors by conducting the tests identified in the Program Unit Test Plan. It is important that the tester's attitude reflect the objective of finding errors. If the attitude is one of defending the quality of the code, then errors will be overlooked. Unit Test Steps The process of conducting the unit test consists of several steps, including: y y y y review program unit, conduct the code execution tests, identify and resolve any discrepancies, determine that the test is complete.

Review Program Unit Prior to running the program to test the program unit, conduct a review of the program unit using static analysis techniques, (e.g., a desk check, inspection, or structured walk-through).

Automated static analysis tools can be used to assist with this process.

Conduct the Code Execution Tests

Conduct the code execution tests defined in the Unit Test Plan using dynamic analysis techniques.

Automated dynamic analysis tools can be used to assist with this process, (e.g., code coverage monitors, memory analysis tools, in addition to analysis features available with application development environments, such as Visual Basic by Microsoft Corporation).

Test program units one at a time. This approach makes the identification of errors easier, because there are fewer places to look for problems.

Program units are tested immediately after coding of the unit is complete, which means the modules(s) the unit interfaces with may or may not be available. To test the receipt of input data, it may be necessary to use temporary modules that simulate the real modules.

Use of Drivers and Stubs

A driver module is used to simulate a calling module and call the program unit being tested by passing input arguments. The driver can be written in various ways, (e.g., prompt interactively for the input arguments or accept input arguments from a file).

To test the ability of the unit being tested to call another module, it may be necessary to use a different temporary module, called a stub module. More than one stub may be needed, depending on the number of programs the unit calls. The stub can be written in various ways, (e.g., return control immediately or return a message that indicates it was called and report the input parameters received).

Identify and Resolve Any Discrepancies

After conducting the test, compare the actual result to the expected result. If there is no difference, record the test as non-discrepant on the Program Unit Test Plan.

If there is a difference, record the discrepancy on the Program Unit Test Plan, and determine if the discrepancy is the result of an error in the code or an error in the expected result.

If the code is in error, use the debugging technique to:

y y y

isolate the cause of the error, correct and recompile the program, retest the program.

If the expected result is in error, correct the expected result, and rerun the test.

When all tests have been executed and errors corrected, re-execute the full unit test to ensure that no new errors were created during error correction.

Record any metrics as required by the unit test procedures, (e.g., the types of errors, such as error handling, failure to reinitialize, the number of errors found, the number of lines of code, and the number of interfaces). Use evaluating test metrics to identify methods for gathering test metrics.

Determine the Test is Complete

The unit test is complete when you:

y y y y

finish executing the tests itemized in the Program Unit Test Plan, are satisfied the code matches the design, finish correcting and retesting identified errors, document the test results in the Program Unit Test Plan.

Further readings
Static analysis is completed without using the actual system. The advantage of static analysis is the ability to complete the process prior to actual coding. Prevention of errors is more cost effective than the correction of errors. Apply the static analysis processes to the detailed design specifications and to the source code produced for each program. Automated test tools can assist with the static analysis processes. Some tools are used for static analysis only. Some tools have both static and dynamic analysis capabilities.

Static Analysis Processes

Static analysis processes include:

yDesk checking (see details below) and Independent Review  y  y  Differences Between Inspections and Walk-through  Inspections and walk-throughs are similar, but there are important differences:  y An inspection is more formal and rigorous and focuses on error detection in detail, as opposed to a walk-through which takes a more global view of overall accuracy,  y An inspection requires that the number of participants be kept to a minimum, as opposed to a walk-through which can encompass a large review group.  Benefits of Inspections and Walk-throughs  Because inspection meetings and walk-throughs involve a group setting and involve review by someone other than the author, there are two additional benefits that result from these processes.   First, staff are more conscientious when they know that their work will be inspected by someone else.   Second, preparation for an inspection or walk-through, and participation in the process, forces the presenter to organize and clarify his or her thinking. If the inspection or walk-through pertains to the detailed design, the designer must be clear on the translation of the structural design specification to Structured Walk-through Inspection Meetings

the detailed design specification. If the inspection or walk-through pertains to the program code, the program author must be clear on the detailed design and the workings of the program.  Tips and Hints  The static analysis processes can also be applied to other activities within the project development cycle, such as review of functional design specifications and review of structural design specifications.  DESK CHECKING AND INDEPENDENT REVIEW  Desk Checking  Desk checking is conducted by the author to complete detailed design specification or program source code review activities that are not automated. For example:  y  y compare the detailed design specifications to the structural design specifications for a design review, and compare the source code to the detailed design specifications for a code review,  y review and analyze the information provided by automated tools, e.g., cross-reference lists, call-structure lists, syntax errors, and standards errors,  Independent Reviews Desk checking can be conducted by an individual other than the author, such as the author's peers, and is called an independent review. An independent review does not require the reviewer to be in the same location as the author.  Multiple Review Approach read the detailed design specification or the program source code to verify accuracy,

Desk checking or an independent review can be conducted by completing multiple passes for one or more criteria, (e.g., one pass for adherence to standards, one pass for proper definition and usage of variables, and so on). Each independent review can be conducted by a person who is expert on a particular criteria. For example, the team leader may review for application of standards and a technical expert may review for compliance with performance issues.   SEQUENCE OF DATA OPERATIONS  Normal Sequence One area that is considered error prone is the sequence of data operations. The normal sequence of data operations is:  y  y  y  When an incorrect sequence of data operations is present, note it as an anomaly and investigate further to determine if there is an error.   Incorrect Sequences  The following sequences are likely to be in error:  y define/define - if the variable is defined twice, the first define is never used, undefine (the value is no longer available).  use (the unchanged value is referenced, e.g., an output statement), define (a variable is assigned a value, e.g., through an input statement),

 y  y  y  Dynamic analysis occurs after the coding process is complete, and is used to identify errors in the source code. In preparation for the dynamic analysis process, use knowledge of the detailed design and program code to prepare test cases, which identify the items to be tested and predict the expected result. During the dynamic testing process, the program is executed and the actual result is compared to the predicted result. Any discrepancies are investigated to substantiate suspected errors. Automated test tools can assist with the dynamic analysis processes. Some tools are used for dynamic analysis only while some tools have both static and dynamic analysis capabilities.  Dynamic Analysis Processes  Dynamic analysis processes focus on particular test approaches and criterion including:  CODE COVERAGE TESTING  Types of Code Coverage Testing  Code coverage testing focuses on the control structure of a program. There are different levels of code coverage testing, including:  y y y statement testing, branch testing, path testing. undefine only, undefine/use, undefine/define - the variable must first be defined and used. use/define, use only, or use/undefine - the variable must be defined first, define/undefine - the variable is never used,

 Statement Testing  Statement testing is one of the highest level and least effective methods of testing. Statement testing ensures that each statement is executed from beginning to end, but does not exercise all decisions or paths.  Branch Testing  Branch testing is recommended as the minimum acceptable form of testing. For each decision point, branch testing exercises each true and false path at least once, and ensures that each statement is exercised.  Path Testing  Pure path testing exercises all possible paths and is the optimum form of code coverage testing. However, this type of testing is difficult to achieve cost effectively. To take advantage of the benefits of path testing and make it achievable, minimize the number of test cases by focusing on efficient and effective testing methods. For example,   y Prepare test cases that test as many untested true paths as possible at one time. (False paths must be tested one at a time, because one error may take precedence over another.)  y Prepare test cases that test true and false conditions efficiently by avoiding tests that fail to provide additional information, (e.g., if a value of 9 has been used to test an IF condition where x<10, nothing is gained by testing a value of 8).  y Prepare test cases that focus on paths that are known to be error prone, (e.g., boundary values, null values, or other criteria identified through error detection metrics).  

DATA FLOW TESTING   Data flow testing emphasizes the accurate use of data rather than just the control structure. Traditional data flow testing is the process of focusing on the definition of a variable and proper usage of the value assigned to the variable. Emphasis is on testing the patterns of definitions and uses of variables.   Traditional Data Flow Testing  After a variable is assigned a value or defined, it can be used in different places. To apply data flow testing, use data applicable to the variable being scrutinized that will exercise the usage being scrutinized.  In data flow testing, a value is considered to be defined if there is a statement that assigns a value, such as when it appears on the lefthand side of an assignment statement or in an input statement. Traditional data flow testing follows the value through its uses to ensure data integrity.   A variable is used when it is either referenced through an output statement or on the righthand side of an assignment statement (computational use), or referenced when control is transferred conditionally from one block of code to another (predicate use). A block of code is a sequence of statements that can only be entered through the first statement, and when the statement is executed, all remaining statements are executed in order.   Data flow testing focuses on the flow of data between blocks of code. For computational use, the focus is only on the global use of variables. Global uses occur when a variable is used outside the block in which it is defined. By definition, predicate uses occur within a block separate from the one in which the definition occurs.