Designing Unit Test Cases Vivek Gulati COMP 595

Designing Unit Test Cases Vivek Gulati COMP 595 VAV Dept. of Computer Science California State University, Northridge

Designing Unit Test Cases o o Copyright of IPL, Information Processing Ltd IPL is an independent software house founded in 1979 and based in Bath IPL has developed and supplies the Ada. TEST and Cantata software verification products. Ada. TEST and Cantata have been produced to these standards.

Contents o o o Why Unit Test? Organizational Approaches for Unit Testing Designing Unit Test Cases n n o Development of test specification Test case design techniques Conclusion

Contents o o o Why Unit Test? Organizational Approaches for Unit Testing Designing Unit Test Cases n n o Development of test specification Test case design techniques Conclusion

What is Unit Testing? o The unit test is the lowest level of testing performed during software development where individual units of software tested in isolation from other parts of a program.

What is Unit Testing? o o In a conventional structured programming language, such as C, the unit to be tested is traditionally the function or sub-routine. In object oriented languages such as C++, the basic unit to be tested is the class.

Popular Misconceptions o o o It Consumes Too Much Time It Only Proves That the Code Does What the Code Does “I'm too Good a Programmer to Need Unit Tests” Integration Tests will Catch all the Bugs Anyway It is not Cost Effective

Some Figures

Contents o o o Why Unit Test? Organizational Approaches for Unit Testing Designing Unit Test Cases n n o Development of test specification Test case design techniques Conclusion

Organizational Approaches o Top Down Testing o Bottom Up Testing o Isolation Testing

Top Down Testing

Advantages o o Early integration of units before the software integration phase. Development time can be shortened by overlapping unit testing with the detailed design and code phases of the software lifecycle.

Disadvantages o o Because of stubs testing is complicated and expensive to develop and maintain. Changes to a unit often impact the testing of sibling units and units below it in the hierarchy.

Bottom up Testing

Advantages o o Early integration of units before the software integration phase. Only test drivers are required. This can make unit tests near the bottom of the unit hierarchy relatively simple.

Disadvantages o o o As testing progresses up the unit hierarchy, testing becomes more complicated, and expensive. Changes to a unit often impact the testing of units above it in the hierarchy. The first units to be tested are the last units to be designed, so unit testing cannot overlap with the detailed design phase of the software lifecycle.

Isolation Testing

Advantages o o o It is easier to test an isolated unit Drivers and stubs simpler as only one unit is being tested Changes to a unit does not impact other units.

Contents o o o Why Unit Test? Organizational Approaches for Unit Testing Designing Unit Test Cases n n o Development of test specification Test case design techniques Conclusion

Test Design o Test design stages: n n Test consists strategy planning specification procedure of following

Contents o o o Why Unit Test? Organizational Approaches for Unit Testing Designing Unit Test Cases n n o Development of test specification Test case design techniques Conclusion

Developing Unit Test Specifications o o Tests should be designed before the code is written. A unit test specification comprises a sequence of unit test cases.

Developing Unit Test Specifications o Each unit test case should include four essential elements: n A statement of the initial state of the unit, the starting point of the test case n The inputs to the unit n What the test case actually tests, in terms of the functionality of the unit and the analysis used in the design of the test case n The expected outcome of the test case

Developing Unit Test Specifications o Six step general process for developing a unit test specification as a set of individual unit test cases. n n n Step Step 1 2 3 4 5 6 - Make it Run Positive Testing Negative Testing Special Considerations Coverage Tests Coverage Completion

Step 1 - Make it Run o o The purpose of the first test case in any unit test specification should be to execute the unit under test in the simplest way possible. Suitable techniques: n n Specification derived tests Equivalence partitioning

Developing Unit Test Specifications o Six step general process for developing a unit test specification as a set of individual unit test cases. n n n Step Step 1 2 3 4 5 6 - Make it Run Positive Testing Negative Testing Special Considerations Coverage Tests Coverage Completion

Step 2 - Positive Testing o o Test cases should be designed to show that the unit under test does what it is supposed to do. Suitable techniques: n Specification derived tests n Equivalence partitioning n State-transition testing

Developing Unit Test Specifications o Six step general process for developing a unit test specification as a set of individual unit test cases. n n n Step Step 1 2 3 4 5 6 - Make it Run Positive Testing Negative Testing Special Considerations Coverage Tests Coverage Completion

Step 3 - Negative Testing o o Test cases should be enhanced and further test cases should be designed to show that the software does not do that it is not supposed to do. Suitable techniques: n Error guessing n Boundary value analysis n Internal boundary value testing n State-transition testing

Developing Unit Test Specifications o Six step general process for developing a unit test specification as a set of individual unit test cases. n n n Step Step 1 2 3 4 5 6 - Make it Run Positive Testing Negative Testing Special Considerations Coverage Tests Coverage Completion

Step 4 - Special Considerations o o Where appropriate, test cases should be designed to address issues related to performance, safety and security requirements. Suitable techniques: n Specification derived tests

Developing Unit Test Specifications o Six step general process for developing a unit test specification as a set of individual unit test cases. n n n Step Step 1 2 3 4 5 6 - Make it Run Positive Testing Negative Testing Special Considerations Coverage Tests Coverage Completion

Step 5 - Coverage Tests o o Add more test cases to the unit test specification to achieve specific test coverage objectives. Suitable techniques: n Branch testing n Condition testing n Data definition-use testing n State-transition testing

Test Execution o o o At this point the test specification can be used to develop an actual test procedure and executed. Execution of the test procedure will identify errors in the unit which can be corrected and the unit re-tested. Running of test cases will indicate whether coverage objectives have been achieved. If not…

Developing Unit Test Specifications o Six step general process for developing a unit test specification as a set of individual unit test cases. n n n Step Step 1 2 3 4 5 6 - Make it Run Positive Testing Negative Testing Special Considerations Coverage Tests Coverage Completion

Step 6 - Coverage Completion o Where coverage objectives are not achieved, analysis must be conducted to determine why. Failure to achieve a coverage objective may be due to: n Infeasible paths or conditions n Unreachable or redundant code n Insufficient test cases

Step 6 - Coverage Completion o o Some insight into the code is required to achieve coverage targets. Suitable techniques: n Branch testing n Condition testing n Data definition-use testing n State-transition testing

Contents o o o Why Unit Test? Organizational Approaches for Unit Testing Designing Unit Test Cases n n o Development of test specification Test case design techniques Conclusion

Test Case Design Techniques o Black box (functional) n n o White box (structural) n n o Specification derived tests Equivalence partitioning Boundary value analysis State-transition testing Branch testing Condition testing Data definition-use testing Internal boundary value testing Other n Error guessing

Test Case Design Techniques o Black box (functional) n n o o Specification derived tests Equivalence partitioning Boundary value analysis State-transition testing White box (structural) Other

Specification Derived Tests o o o Test cases are designed by walking through the relevant specifications. Each test case should test one or more statements of specification. Positive test case design technique.

Example Specification n n o o o Input - real number Output - real number When given an input of 0 or greater, the positive square root of the input shall be returned. When given an input of less than 0, the error message "Square root error - illegal negative input" shall be displayed and a value of 0 returned. The library routine Print_Line shall be used to display the error message.

Example Test Cases o o Test Case 1: Input 4, Return 2 o Exercises the first statement in the specification o ("When given an input of 0 or greater, the positive square root of the input shall be returned. "). Test Case 2: Input -10, Return 0, Output "Square root error - illegal negative input“ using Print_Line. o Exercises the second and third statements in the specification o ("When given an input of less than 0, the error message "Square root error - illegal negative input" shall be displayed and a value of 0 returned. The library routine Print_Line shall be used to display the error message. ").

Test Case Design Techniques o Black box (functional) n n o o Specification derived tests Equivalence partitioning Boundary value analysis State-transition testing White box (structural) Other

Equivalence Partitioning o o o It is based upon splitting the inputs and outputs of the software under test into a number of partitions Test cases should therefore be designed to test one value in each partition. Still positive test case design technique.

Example Partitions & Test Cases

Test Case Design Techniques o Black box (functional) n n o o Specification derived tests Equivalence partitioning Boundary value analysis State-transition testing White box (structural) Other

Boundary Value Analysis o o Similar to Equivalence Partitioning Assumes that errors are most likely to exist at the boundaries between partitions. Test cases are designed to exercise the software on and at either side of boundary values. Incorporates a degree of negative testing into the test design

Example Boundaries

Example Boundary Test Cases

Test Case Design Techniques o Black box (functional) n n o o Specification derived tests Equivalence partitioning Boundary value analysis State-transition testing White box (structural) Other

State-Transition Testing o o o Used where the software has been designed as a state machine Test cases are designed to test transition between states by generating events Negative testing can be done by using illegal combinations of states and events

Test Case Design Techniques o o Black box (functional) White box (structural) n n o Branch testing Condition testing Data definition-use testing Internal boundary value testing Other

Branch Testing o o Designed to test the control flow branches E. g. if-then-else

Test Case Design Techniques o o Black box (functional) White box (structural) n n o Branch testing Condition testing Data definition-use testing Internal boundary value testing Other

Condition Testing o o o Used to complement branch testing It tests logical conditions E. g. while(a<b), for(; ; )

Test Case Design Techniques o o Black box (functional) White box (structural) n n o Branch testing Condition testing Data definition-use testing Internal boundary value testing Other

Data Definition-Use Testing o Test cases to test pairs of data definitions and uses.

Test Case Design Techniques o o Black box (functional) White box (structural) n n o Branch testing Condition testing Data definition-use testing Internal boundary value testing Other

Internal Boundary Value Testing o Implements test cases when boundaries and partitions can only be established by looking at the code

Example Internal Boundary Test Cases o o o Test Case 1: Error just greater than the desired accuracy Test Case 2: Error equal to the desired accuracy Test Case 3: Error just less than the desired accuracy

Test Case Design Techniques o o o Black box (functional) White box (structural) Other n Error guessing

Error Guessing o o o Based solely on the experience of the test designer The test cases are designed for the values which can generate errors If properly implemented it can be the most effective way of testing

Contents o o o Why Unit Test? Organizational Approaches for Unit Testing Designing Unit Test Cases n n o Development of test specification Test case design techniques Summary

Summary o o o Unit testing provides the earliest opportunity to catch the bugs And fixing them at this stage is the most economical Mainly three organizational approaches to Unit Testing Whatever approach we take unit test cases should be developed before the code Six step process to develop the test specifications Black Box and White Box techniques to develop individual test cases

Thank You Questions?