Unit Testing
CS 414 – Software Engineering I
Don Bagert
Rose-Hulman Institute of Technology
January 16, 2003
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
2
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
3
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
4
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
5
Test Plan Creation
Order:
1.
2.
3.
Validation Test Plan (from Requirements Specification)
Integration Test Plan (from Design Document)
Unit Test Plan (from source code)
CS 414 Software Engineering I - Unit Testing - January 16, 2003
6
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
7
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
8
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
CS 414 Software Engineering I - Unit Testing - January 16, 2003
9
Look at the Example Code
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
11
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)
CS 414 Software Engineering I - Unit Testing - January 16, 2003
12
Convert the Example Code
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
14
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
15
Cyclomatic Complexity
(continued)
•
Can be computed in one of three ways
1.
2.
3.
Number of edges – Number of Nodes + 2
Number of regions created in the two-dimensional plane
by the flow graph
Number of predicates + 1
CS 414 Software Engineering I - Unit Testing - January 16, 2003
16
Compute V(G) for the Flow Graph
Basis Path Testing Steps
(continued)
3.
Determine the set of linearly independent
paths
CS 414 Software Engineering I - Unit Testing - January 16, 2003
18
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
CS 414 Software Engineering I - Unit Testing - January 16, 2003
19
Determine the Linearly
Independent Paths
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
CS 414 Software Engineering I - Unit Testing - January 16, 2003
21
Create Test Cases from the Paths
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
23
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
CS 414 Software Engineering I - Unit Testing - January 16, 2003
24