1. Unit Testing CS 414 – Software Engineering I Don Bagert Rose-Hulman Institute of Technology January 16, 2003

2. CS 414 Software Engineering I - Unit Testing - January 16, 20032 Outline Overview of Testing Test Plan Creation Test Plan Implementation Unit Testing Techniques Basis Path Testing Steps –Hands-on Example Summary

3. CS 414 Software Engineering I - Unit Testing - January 16, 20033 Overview of Testing Software testing is inherently limited in nature! Why? Because there in general there is no method to determine the “perfect” set of test cases (It’s a variation of the halting problem) That said, the alternatives (e.g. formal proofs of correctness) are very time-consuming and therefore most people use testing

4. CS 414 Software Engineering I - Unit Testing - January 16, 20034 Overview of Testing (continued) The main objective of testing: Create test cases that have a high probability of finding an error

5. CS 414 Software Engineering I - Unit Testing - January 16, 20035 Overview of Testing (continued) Important Testing Principles: –Traceability to customer requirements –Top-down, early planning –Bottom-up test Implementation

6. CS 414 Software Engineering I - Unit Testing - January 16, 20036 Test Plan Creation Order: 1.Validation Test Plan (from Requirements Specification) 2.Integration Test Plan (from Design Document) 3.Unit Test Plan (from source code)

7. CS 414 Software Engineering I - Unit Testing - January 16, 20037 Test Implementation Order: 1.Unit Test Plan (tests functions and methods) 2.Integration Test Plan (test classes and subsystems) 3.Validation Test Plan (test entire software)

8. CS 414 Software Engineering I - Unit Testing - January 16, 20038 Unit Testing Techniques Unit and integration testing is generally “glass-box” (also called “white-box”) i.e. it is done with knowledge of the code Validation testing is always “black-box” i.e. it is done from the user’s point-of-view, without knowledge of the code

9. CS 414 Software Engineering I - Unit Testing - January 16, 20039 Unit Testing Techniques (continued) One of the most effective methods of glass-box testing at the unit level is basis path testing First proposed by Tom McCabe in 1976 Uses graph theory to develop a set of test cases which ensures that each statement and branch in a unit is executed in at least one case

10. Look at the Example Code

11. CS 414 Software Engineering I - Unit Testing - January 16, 200311 Basis Path Testing Steps 1.Using the code for the unit, draw the corresponding flow graph

12. CS 414 Software Engineering I - Unit Testing - January 16, 200312 Flow Graph Fundamentals The flow graph is similar to a flowchart There are nodes (vertices) for –Assignment and procedure call statements –Predicates (conditional expressions) If the predicate involves an “and” or an “or”, multiple nodes will be needed –All “End If”, “End While” and “End Case” clauses A linear sequence of nodes can be combined into one node (we’ll talk about this later)

13. Convert the Example Code

14. CS 414 Software Engineering I - Unit Testing - January 16, 200314 Basis Path Testing Steps (continued) 2.Determine the cyclomatic complexity of the resultant flow graph

15. CS 414 Software Engineering I - Unit Testing - January 16, 200315 Cyclomatic Complexity A software metric that provides a quantitative measure of the complexity of a unit Is denoted as V(G)

16. CS 414 Software Engineering I - Unit Testing - January 16, 200316 Cyclomatic Complexity (continued) Can be computed in one of three ways 1.Number of edges – Number of Nodes + 2 2.Number of regions created in the two-dimensional plane by the flow graph 3.Number of predicates + 1

17. Compute V(G) for the Flow Graph

18. CS 414 Software Engineering I - Unit Testing - January 16, 200318 Basis Path Testing Steps (continued) 3.Determine the set of linearly independent paths

19. CS 414 Software Engineering I - Unit Testing - January 16, 200319 Rules of Thumb (Customized by Don) Each path should introduce at least one new edge In general, each new path should introduce as few new edges as possible Each edge should be included in at least one path

20. Determine the Linearly Independent Paths

21. CS 414 Software Engineering I - Unit Testing - January 16, 200321 Basis Path Testing Steps (continued) 4.Prepare test cases that will force execution of each path in the basis set Note: One test case might be usable for more than one path Some paths on their own may not be possible

22. Create Test Cases from the Paths

23. CS 414 Software Engineering I - Unit Testing - January 16, 200323 Unit Testing Techniques (revisited) Basis path testing is only one technique for generating test cases Several techniques can be used, and the union of the test case sets can be used to create the Unit Test Plan

24. CS 414 Software Engineering I - Unit Testing - January 16, 200324 Summary Software testing is inherently limited in nature The main objective of testing is to create test cases that have a high probability of finding an error Test planning is top-down Test implementation is bottom-up The “unit” in unit testing refers to an individual function or method Unit testing is usually “glass-box” in that it is done with knowledge of the code Basis path testing ensures that each statement and branch in a unit is executed at least once