DYNAMIC UNIT TESTING
MODULE: 2
Presented by:
Manju Mathews
DYNAMIC UNIT TESTING
• Execution-based unit testing
• A program unit is executed in isolation
• 1. A unit under test is taken out of its actual execution environment
• 2. The actual execution environment is emulated by writing more code
• 3. The compiled aggregate is executed with selected inputs
• The outcome observed :
• straightforward observation on a screen, logging on files, and software
instrumentation of the code to reveal run time behavior
• The result is compared with the expected outcome
• Any difference => a failure and the fault is in the code
Dynamic unit test environment
Figure 1: Dynamic unit test envt
Dynamic unit test environment
• An environment for dynamic unit testing is created by emulating the
context of the unit under test
• The context of a unit test consists of two parts:
• 1. a caller of the unit
• 2. all the units called by the unit
• The caller unit is known as a test driver, and all the emulations of the
units called by the unit under test are called stubs.
• The test driver and the stubs are together called scaffolding.
Functions of Driver and Stub
• Test Driver:
• A program that invokes the unit under test
• The unit under test executes with input values received from the
driver , returns a value to the driver upon termination
• The driver compares the actual outcome with the expected outcome
and reports the ensuing test result
• The test driver functions as the main unit in the execution process
• The driver facilitates compilation, provides input data to the unit
under test in the expected format
Functions of Driver and Stub
• A stub - “dummy subprogram” that replaces a unit that is called by
the unit under test
• Stubs replace the units called by the unit under test
• Performs two tasks:
• It shows an evidence that the stub was called (printing a message)
• The stub returns a precomputed value to the caller so that the unit under test
can continue its execution
Functions of Driver and Stub
• The driver and the stubs are NOT discarded after the unit testing but
reused in the future in regression testing of the unit
• For each unit, there should be one dedicated test driver and several stubs
as required
• Driver should have its own segregated set of input data
• Capability to automatically determine the success or failure of the unit
under test for each input test data
• The driver should also check for memory leaks and problems in allocation
and deallocation of memory
• If the module opens and closes files, the test driver should check that
these files are left in the expected open or closed state after each test
Functions of Driver and Stub
• Tightly coupled with the unit under test and should accompany the
unit throughout its life cycle
• Should be reusable and maintainable
• Finally, the test driver and stubs should be reviewed, cross-referenced
with the unit for which these are written, and checked in to the
version control system as a product along with the unit
Selection of test data
• Selection of test data is broadly based on the following techniques:
• Control Flow Testing
• Data Flow Testing
• Domain Testing
• Functional program testing
A Control Flow Graph (CFG)
• Graphical representation of control flow
• Shows logical structure of pgm in a visual manner
• Control flow graph is process oriented.
• Control flow graph shows all the paths that can be traversed during a
program execution.
• Directed graph
• Edges -> control flow paths, nodes -> basic blocks
Eg: CFG
• If-else:
Eg. For CFG
Control Flow Software Testing
• Uses program’s control flow as a model
• Structural testing strategy
• White box testing
• For control flow testing, all the structure, design, code and
implementation of the software should be known to the testing team
• Used by developers to test their own code
Data Flow Testing
• A type of structural testing
• White box testing
• Used to find the test paths of a program according to the locations of
definitions and uses of variables in the program
• It has nothing to do with data flow diagrams
• It is concerned with:
• Statements where variables receive values,
• Statements where these values are used or referenced
Data Flow Testing
• Data Flow Testing uses the control flow graph to find the situations
that can interrupt the flow of the program
• Designs test cases that cover control flow paths around variable
definitions and usage in the modules
• The anomalies detected are:
• A variable is defined but not used or referenced,
• A variable is used but never defined,
• A variable is defined twice before it is used
ADVANTAGES OF DATA FLOW TESTING
• Data Flow Testing is used to find the following issues-
• To find a variable that is used but never defined,
• To find a variable that is defined but never used,
• To find a variable that is defined multiple times before it is use,
• Deallocating a variable before it is used.
Domain Testing
• In control flow and data flow testing, no specific types of faults are
explicitly considered for detection.
• Domain testing takes a new approach to fault detection.
• A domain is a set of input values for which the program performs the
same computation for every member of the set.
• In this approach, a category of faults called domain errors are defined
and then test data are selected to catch those faults.
• If a program has domain errors, those will be revealed by the test
cases
Domain Testing
• Functional Testing technique , White Box Testing
• Boundary testing and “Equivalence class analysis.”
• The output of a system is tested with a minimal number of inputs to
ensure that the system does not accept invalid and out of range
input values
Functional Program Testing
• Software testing that validates the software system against the
functional requirements/specification
• Involves black box testing , not concerned about the source code of
the application
• It tests:
• Mainline functions: Testing the main functions of an application
• Basic Usability:
• Accessibility: Checks the accessibility of the system for the user
• Error Condition : It checks whether suitable error messages are displayed
How to do Functional Testing ?
• Understand the Functional Requirements
• Identify test input or test data based on requirements
• Compute the expected outcomes with selected test input values
• Execute test cases
• Compare actual and computed expected results
• Thank you
Functional Program Testing
• In functional program testing one performs the following steps:
• (i) identify the input and output domains of a program;
• (ii) for a given input domain, select some special values and compute
the expected outcome;
• (iii) for a given output domain, select some special values and
compute the input values that will cause the unit to produce those
output values; and
• (iv) consider various combinations of the input values chosen above
Control Flow Testing
• Outline:
• (i) draw a control flow graph from a program unit;
• (ii) select a few control flow testing criteria;
• (iii) identify paths in the control flow graph to satisfy the selection
criteria;
• (iv) derive path predicate expressions from the selected paths; and
• (v) by solving the path predicate expression for a path, generate
values of the inputs to the program unit that are considered as a test
case to exercise the corresponding path.
Data Flow Testing
• (i) draw a data flow graph from a program unit
• (ii) select a few data flow testing criteria
• (iii) identify paths in the data flow graph to satisfy the selection
criteria
• (iv) derive path predicate expressions from the selected paths
• (v) by solving the path predicate expression, generate values of the
inputs to the program unit that are considered as a test case to
exercise the corresponding path
• Domain testing :[Link]