Unit Testing

CS 414 – Software Engineering IDon Bagert

Rose-Hulman Institute of TechnologyJanuary 16, 2003

CS 414 Software Engineering I - Unit Testing - January 16, 2003 2

Outline

• Overview of Testing• Test Plan Creation• Test Plan Implementation• Unit Testing Techniques• Basis Path Testing Steps

– Hands-on Example

• Summary

CS 414 Software Engineering I - Unit Testing - January 16, 2003 3

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

CS 414 Software Engineering I - Unit Testing - January 16, 2003 4

Overview of Testing(continued)

• The main objective of testing:

Create test cases that have a high probability of finding an error

CS 414 Software Engineering I - Unit Testing - January 16, 2003 5

Overview of Testing(continued)

• Important Testing Principles:– Traceability to customer requirements– Top-down, early planning– Bottom-up test Implementation

CS 414 Software Engineering I - Unit Testing - January 16, 2003 6

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)

CS 414 Software Engineering I - Unit Testing - January 16, 2003 7

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)

CS 414 Software Engineering I - Unit Testing - January 16, 2003 8

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

CS 414 Software Engineering I - Unit Testing - January 16, 2003 9

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

Look at the Example Code

CS 414 Software Engineering I - Unit Testing - January 16, 2003 11

Basis Path Testing Steps

1. Using the code for the unit, draw the corresponding flow graph

CS 414 Software Engineering I - Unit Testing - January 16, 2003 12

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)

Convert the Example Code

CS 414 Software Engineering I - Unit Testing - January 16, 2003 14

Basis Path Testing Steps(continued)

2. Determine the cyclomatic complexity of the resultant flow graph

CS 414 Software Engineering I - Unit Testing - January 16, 2003 15

Cyclomatic Complexity

• A software metric that provides a quantitative measure of the complexity of a unit

• Is denoted as V(G)

CS 414 Software Engineering I - Unit Testing - January 16, 2003 16

Cyclomatic Complexity(continued)

• Can be computed in one of three ways1. 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

Compute V(G) for the Flow Graph

CS 414 Software Engineering I - Unit Testing - January 16, 2003 18

Basis Path Testing Steps(continued)

3. Determine the set of linearly independent paths

CS 414 Software Engineering I - Unit Testing - January 16, 2003 19

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

Determine the Linearly Independent Paths

CS 414 Software Engineering I - Unit Testing - January 16, 2003 21

Basis Path Testing Steps(continued)

1. 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

Create Test Cases from the Paths

CS 414 Software Engineering I - Unit Testing - January 16, 2003 23

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

CS 414 Software Engineering I - Unit Testing - January 16, 2003 24

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