CHAPTER 6
COURSE NAME UNIT TESTING
SOFTWARE
SOFTWARE QUALITY
ENGINEERING
AND TESTING
(UNDERGRADUATE)
CSC 4133
(UNDERGRADUATE)
Chapter 6: Unit Testing
MMH S.2
UNIT TESTING
Tests a small software unit at a time, which is typically performed by the individual programmer
who implemented the unit prior to Integration testing
Unit Testing is usually performed by using the White Box Testing method
Lower level/ initial level testing
❑ Static Unit Testing
❑ Dynamic Unit Testing
❖ Static and Dynamic analysis are complementary in nature
❖ It is recommended that static unit testing be performed prior to
the dynamic unit testing
Chapter 6: Unit Testing
MMH S.3
STATIC UNIT TESTING (REVIEW CODE)
Code is examined at compile time over all possible behaviors
that might arise during run time
Code of each unit is validated against requirements of the
unit by reviewing the code
In static unit testing, code is reviewed by applying techniques:
- Walkthrough (informal)
- Code Inspection (formal)
Black-box and White-box testing
Chapter 6: Unit Testing
MMH S.4
DYNAMIC UNIT TESTING (EXECUTE CODE)
Execute at Run time testing of Code
Black-box testing
Chapter 6: Unit Testing
MMH S.5
STEPS IN THE CODE REVIEW PROCESS
Step 1: Readiness – The author of the code unit ensures that the unit under test is ready for
review. A unit is said to be ready if it satisfies the following criteria – Completeness, Minimal
functionality, Readability, Complexity, Requirements and Design documents
Step 2: Preparation – Each reviewer develops the following: List of questions, Potential Change
Request (CR), Suggested improvement opportunities
Step 3: Examination – the examination process consists of the following:
o The author makes a presentation
CR (Change Request) includes the following details:
o The reviewer reads the code
Give a brief description of the issue
o The record keeper documents the CR
Assign a priority level (major or minor) to a CR
o Moderator ensures the review is on track Assign a person to follow it up
Set a deadline for addressing a CR
Chapter 6: Unit Testing
MMH S.6
STEPS IN THE CODE REVIEW PROCESS
Step 4: Re-work – At the end of the meeting, the record keeper produces a summary of the
meeting that includes the following information:
Make the list of all the CRs
Make a list of improvements/maintenance
(corrective, perfective, adaptive, preventive maintenance)
Record the minutes of the meeting (optional)
Author works on the CRs to fix the issue
Step 5: Validation
CRs are independently validated (e.g. regression testing)
Step 6: Exit
A summary report of the meeting minutes is distributed
among the stakeholder who have requested and who will
affected by the changes
Chapter 6: Unit Testing
MMH S.7
CODE REVIEW METRICS
❑ Identify the Cost of Development and Change
Cost may calculate by How many lines the developer can write in each hour and How
much money to pay him for each hour that finds out the cost of each line of code
The number of lines of code (LOC) reviewed per hour
The number of CRs generated per thousand lines of code (KLOC)
❑ Identify the Cost of Testing process
Number of CRs generated per hour
The total number of hours spend on code review process
Chapter 6: Unit Testing
MMH S.8
DYNAMIC UNIT TESTING
Execution-based unit testing is referred to as dynamic unit testing
A program unit is executed in isolation, and the outcomes of program execution are observed
The environment of a unit is emulated and tested in isolation
IDE checks every statement in the program for errors while writing
The caller unit is known as test driver
o A test driver is a program that invokes the unit under test (UUT)
o It provides input data to UUT and report the test result
The emulation of the units called by the UUT are called stubs
o It is a “sub-program” that replaces a unit that is called by the UUT
Figure : Dynamic unit test
The test driver and the stubs are together called scaffolding environment
The low-level design document provides guidance for selection of input test data
Chapter 6: Unit Testing
MMH S.9
DYNAMIC UNIT TESTING
❑ Control flow testing
Draw a control flow graph (CFG) from a program unit and Select a few control flow testing criteria
Identify a path in the CFG to satisfy the selection criteria
Derive the path predicate expression from the selection paths and one can generate the data
❑ Data flow testing
Draw a data flow graph (DFG) from a program unit and then follow the procedure described in
control flow testing (e.g. marks conversion and grading in VUES)
❑ Domain testing
A domain error occurs when a specific input data causes the program to execute a wrong path in the
program (e.g. Leave application: for1-5 days recommendation by team lead, 5-10 by PM)
❑ Functional program testing
Input/output domains are defined to compute the input values that will cause the unit to produce
expected output values (e.g. grading in VUES A+ for 90 marks)
Chapter 6: Unit Testing
MMH S.10
DEBUGGING
Debugging Identify the error and potential cause of error (hypothetical hidden errors)
Chapter 6: Unit Testing
MMH S.11
DEBUGGING TECHNIQUES
❑ Identify the error and potential cause of error (hypothetical hidden errors)
❑ Brute force testing
most common; but least efficient
memory dumps are taken, run-time traces are invoked, and the program is loaded with
output statements
❑ Backtracking
common debugging approach that can be used successfully in small programs
source code is traced backward (manually) until the cause is found
❑ Cause elimination
a “cause hypothesis” is devised
if initial tests indicate that a particular cause hypothesis shows promise, data are refined in
an attempt to isolate the bug (c/a-b where the possibility of a-b is zero)
Chapter 6: Unit Testing
MMH S.12
UNIT TESTING IN EXTREME PROGRAMMING
❑ Pair programming in XP
1. Pick a requirement (i.e. story)
2. Write a test case that will verify a small part
of the story and assign a fail verdict to it
3. Write the code that implement particular
part of the story to pass the test
4. Execute all tests
5. Rework on the code, and test the code until
all tests pass
6. Repeat step 2 to step 5 until the story is fully
implemented
Chapter 6: Unit Testing
MMH S.13
UNIT TESTING
A mutation of a program is a modification of the program created by introducing a single,
small, legal syntactic change in the code.
Junit is a framework for performing unit testing of Java programs.
Chapter 6: Unit Testing
MMH S.14
TOOLS FOR UNIT TESTING
Code auditor Test harness
Documenters Performance monitors
Interactive debuggers Network analyzers
Static code (path) analyzer Simulators and emulators
Software inspection support Version control
Test coverage analyzer
Test data generator
Chapter 6: Unit Testing
MMH S.15
REFERENCES
❑ Software Testing And Quality Assurance – Theory and Practice - Kshirasagar Naik & Priyadarshi
Tripathy
❑ Software Quality Engineering: Testing, Quality Assurance and Quantifiable Improvement - Jeff Tian
