1

Object-Oriented Testing

CIS 375

Bruce R. Maxim

UM-Dearborn

2

OO testing Activities

• Review OOA and OOD models

• Class testing after code is written

• Integration testing within subsystems

• Integration testing as subsystems are added to the system

• Validation testing based on OOA use-cases

3

Correctness of OOA/OOA Models

• syntactic correctness– judged by making sure proper modeling

conventions and symbolism were used

• semantic correctness– checking the model's conformance to the

real world problem domain

4

Consistency of OOA/OOD Models - 1

• assess the class-responsibility-collaborator (CRC) model and object-relationship diagram

• review system design– examine the object-behavior model to check

mapping of system behavior to subsystems– review concurrency and task allocation– examine the use-case scenarios and exercise the

user interface design

5

Consistency of OOA/OOD Models - 2

• test object model against the object relationship network to ensure that all design object contain necessary attributes and operations needed to implement the collaborations defined for each CRC card

• review detailed specifications of algorithms used to implement operations using conventional inspection techniques

6

Class Model Assessment - 1

1. Revisit the CRC model and the object-relationship model

2. Inspect the description of each CRC card to determine if a delegated responsibility is part of the collaborator's definition

3. Invert the connection to ensure that each collaborator that is asked for service is receiving requests from a responsible source

7

Class Model Assessment - 2

4. Using the inverted connections from step 3, determine whether – other classes might be required– responsibilities are properly grouped among

classes

5. Determine whether widely requested responsibilities might be combined into a single responsibility

6. Steps 1 to 5 are applied iteratively to each class and during OOA model evaluation

8

OO Unit Testing

• smallest testable unit is the encapsulated class or object

• similar to system testing of conventional software

• do not test operations in isolation from one another

• driven by class operations and state behavior, not algorithmic detail or data flow across module interface

9

OO Integration Testing - 1

• focuses on groups of classes that collaborate or communicate in some manner

• integration of operations one at a time into classes is often meaningless

• regression testing is important as each thread, cluster, or subsystem is added to the system

10

OO Integration Testing - 2

• thread-based testing– testing all classes required to respond to one

system input or event

• use-based testing– test independent classes first– test dependent classes making use of them next

• cluster testing– groups of collaborating classes are tested for

interaction errors

11

OO Validation Testing

• focuses on visible user actions and user recognizable outputs from the system

• validation tests are based on OOA– use-case scenarios– object-behavior model– event flow diagram

• conventional black-box testing methods can be used to drive the validation tests

12

OO Test Case Design

• Each test case should be uniquely identified and be explicitly associated with a class to be tested

• State the purpose of each test

• List the testing details for each test

13

OO Test Case Detail

• states to examine for each object involved• messages and operations to exercised as a

consequence of the test• exceptions that may occur when the object is

tested• external conditions needed to be changed for

the test• supplementary information required to

understand or implement the test

14

OO Test Design Issues

• White-box testing methods can be applied to testing the code used to implement class operations, but not much else

• Black-box testing methods are appropriate for testing OO systems

15

OOP Testing Concerns

• classes may contain operations that are inherited from super classes

• subclasses may contain operations that were redefined rather than inherited

• all classes derived from an previously tested base class need to be thoroughly tested

16

Fault-Base Testing

• best reserved for operations and the class level

• uses the inheritance structure• tester examines the OOA model and

hypothesizes a set of plausible defects that may be encountered in operation calls and message connections and builds appropriate test cases

• misses incorrect specification and errors in subsystem interactions

17

Scenario-Based Testing

• using the user tasks described in the use-cases and building the test cases from the tasks and their variants

• uncovers errors that occur when any actor interacts with the OO software

• concentrates on what the user does, not what the product does

• you are better off spending more time on reviewing the use-cases as they are created and less time on use-case testing

18

Testing Surface Structure and Deep Structure

• Testing surface structure– exercising the structure observable by end-user– often involves observing and interviewing users as

they manipulate system objects

• Testing deep structure– exercising internal program structure established

as part of the system and object design• dependencies• behaviors• communications mechanisms

19

Random Class Testing

• Requires large numbers data permutations and combinations

• Can be very inefficient

• Using partition testing can reduce the number of test cases required

20

Partitioned Class Testing - 1• state-based partitioning

– tests designed in way so that operations that cause state changes are tested separately from those that do not

• attribute-based partitioning– for each class attribute, operations are classified

according to those that• use the attribute• modify the attribute• do not use or modify the attribute

21

Partitioned Class Testing - 2• category-based partitioning

– operations are categorized according to the function they perform:

• Initialization• Computation• Query• Termination

22

Interclass Test Case DesignMultiple Class Testing

• for each client class use the list of class operators to generate random test sequences that send messages to other server classes

• for each message generated determine the collaborator class and the corresponding server object operator

• for each server class operator (invoked by a client object message) determine the message it transmits

• for each message, determine the next level of operators that are invoked and incorporate them into the test sequence

23

Interclass Test Case DesignBehavior Model Testing

• test cases must cover all states in the state transition diagram

• breadth first traversal of the state model can be used (test one transition at a time and only make use of previously tested transitions when testing a new transition)

• test cases can also be derived to ensure that all behaviors for the class have been adequately exercised