Designing Unit Test Cases L 28 Contents Why

Designing Unit Test Cases L 28

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

What is Unit Testing? • 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? • 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.

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

Top Down Testing

In top down testing the unit at the top of the hierarchy is tested first. All called units are replaced by stubs. As the testing progresses the stubs are replaced by actual units.

Bottom up Testing

In bottom up testing the lowest level units are tested first. They are then used to test higher level units. The process is repeated until you reach the top of the hierarchy.

Isolation Testing

In isolation testing there is no particular sequence in which the units are tested. Any unit can be tested any time. Each unit under test requires a test driver to replace the unit that calls it and stubs to replace the unit it calls. In the example the unit test D is the unit under test. And it shows the test drivers and stubs to test the unit D.

Advantages • 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.

Test Design • Test design consists of following stages (applies to all levels of testing, including unit testing): • • Test strategy Test planning Test specification Test procedure First 2 are management activities, test procedure is the implementation. Main part is specification.

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

Test case examples • Test case for ATM • • • • • TC 1 : - succesful card insertion. TC 2 : - unsuccessful operation due to wrong angle card insertion. TC 3: - unsuccesssful operation due to invalid account card. TC 4: - successful entry of pin number. TC 5: - unsuccessful operation due to wrong pin number entered 3 times. TC 6: - successful selection of language. TC 7: - successful selection of account type. TC 8: - unsuccessful operation due to wrong account type selected w/r to that inserted card. TC 9: - successful selection of withdrawl option. TC 10: - successful selection of amount. TC 11: - unsuccessful operation due to wrong denominations. TC 12: - successful withdrawl operation. TC 13: - unsuccessful withdrawl operation due to amount greater than possible balance. TC 14: - unsucceful due to lack of amount in ATM. TC 15: - un due to amount greater than the day limit. TC 16: - un due to server down. TC 17: - un due to click cancel after insert card. TC 18: - un due to click cancel after insert card and pin no. TC 19: - un due to click cancel after language selection, account type selection, withdrawl selection, enter amount

• Test cases for a web page Testing without entering any username and password Test it only with Username Test it only with password. User name with wrong password Password with wrong user name Right username and right password Cancel, after entering username and password. Enter long username and password that exceeds the set limit of characters. • Try copy/paste in the password text box. • After successful sign-out, try “Back” option from your browser. Check whether it gets you to the “signed-in” page. • •

Some terminologies… • Documented Test Cases are referred to as Test Scripts. • Related test cases or test scripts are collectively referred to as Test Suite.

Saple test case unique-test-case-id: Test Case Title Purpose Short sentence or two about the aspect of the system is being tested. If this gets too long, break the test case up or put more information into the feature descriptions. Prereq Assumptions that must be met before the test case can be run. E. g. , "logged in", "guest login allowed", "user testuser exists". Test Data List of variables and their possible values used in the test case. You can list specific values or describe value ranges. The test case should be performed once for each combination of values. These values are written in set notation, one per line. E. g. : login. ID = {Valid login. ID, invalid login. ID, valid email, invalid email, empty} password = {valid, invalid, empty} Steps to carry out the test. See step formating rules below. 1. visit Login. Page 2. enter user. ID 3. enter password 4. click login 5. see the terms of use page 6. click agree radio button at page bottom 7. click submit button 8. see Personal. Page 9. verify that welcome message is correct username Notes and Questions: NOTE QUESTION

Developing Unit Test Specifications • Each unit test case should include four essential elements: • A statement of the initial state of the unit, the starting point of the test case • The inputs to the unit • 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 • The expected outcome of the test case

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

Step 1 - Make it Run • 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: • Specification derived tests • Equivalence partitioning

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

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

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

Step 3 - Negative Testing • 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: • Error guessing • Boundary value analysis • Internal boundary value testing • State-transition testing

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

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

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

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

Test Execution • 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 • Six step general process for developing a unit test specification as a set of individual unit test cases. • • • Step 1 - Make it Run Step 2 - Positive Testing Step 3 - Negative Testing Step 4 - Special Considerations Step 5 - Coverage Tests Step 6 - Coverage Completion

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

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

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

Specification Derived Tests • 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 • 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 • Test Case 1: Input 4, Return 2 • Exercises the first statement in the specification • ("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. • Exercises the second and third statements in the specification • ("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. ").

Equivalence Partitioning • 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

Boundary Value Analysis • 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

State-Transition Testing • 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

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

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

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

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

Example Internal Boundary Test Cases • 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

Error Guessing • 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

Summary • 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