Object-oriented Testing

SIM3302

Objectives

To cover the strategies and tools associated with object oriented testingAnalysis and Design TestingClass Tests Integration TestsValidation TestsSystem Tests

Object-oriented Testing

When should testing begin? Analysis and Design:

Testing begins by evaluating the OOA and OOD models How do we test OOA models (requirements and use cases)? How do we test OOD models (class and sequence diagrams)? Structured walk-throughs, prototypes Formal reviews of correctness, completeness and consistency

Programming: How does OO make testing different from procedural programming? Concept of a ‘unit’ broadens due to class encapsulation Integration focuses on classes and their context of a use case scenario

or their execution across a thread Validation may still use conventional black box methods

Testing Analysisand Design

Syntactic correctness: Are UML and ADT notation used correctly?

Semantic correctness: Does the model reflect the real world problem? Is UML used as intended by its designers? Is the ADT design complete (capturing all the classes and

operations in UML diagram) and understandable? Testing for consistency:

An inconsistent model has representations in one part that are not reflected in other portions of the model

Testing the Class Model

1. Revisit the Use Cases, CRC cards and UML class model. Check that all collaborations are properly represented. Inspect the description of each CRC index card to make sure a delegated responsibility is part of the collaborator’s definition.

Example: in a point of sale system. A read credit card responsibility of a credit sale class is accomplished if

satisfied by a credit card collaborator

2. Invert connections to ensure that each collaborator asked for a service is receiving requests from a reasonable source

Example: a credit card being asked for a purchase amount Have you tested your analysis and design?

If not, who will do it?

Testing OO Code

Class testsClass tests

SystemSystemteststests

IntegrationIntegrationteststests

ValidationValidationteststests

Object-oriented Testing Strategies(1)

Unit Testing Smallest testable unit is the encapsulated class or object Test each operation as part of a class hierarchy

because its class hierarchy defines its context of use Driven by class operations and state behavior, not algorithmic detail and data

flow across module interface Approach:

Test each method (and constructor) within a class Test the state behavior (attributes) of the class between methods

Complete test coverage of a class involves Testing all operations Setting and interrogating all object attributes Exercising the object in all possible state

Test sequences are designed to ensure that relevant operations are exercised State of the class is examined to determine if errors exist

Object-oriented Testing Strategies(2)

Unit Testing …How is class testing different from

conventional testing?Conventional testing focuses on input-

process-output, whereas class testing focuses on each method, then designing sequences of methods to exercise states of a class

But white-box testing can still be applied

Object-oriented Testing Strategies(3)

Integration Testing OO does not have a hierarchical control structure so conventional top-

down and bottom-up integration tests have little meaning Focuses on groups of classes that collaborate in some manner Integration of operations one at a time into a class is often meaningless

Because of direct and indirect interaction of components Thread-based testing

Testing/integrate the set of classes required to respond to one input or event Use-based testing (integrates classes required by one use cas

Begins by testing independent classes that use very few of server classes Next layer of classes (dependent classes) that use the independent classes are

tested next Cluster testing

Groups of collaborating classes are tested for interaction errors Regression testing is important as each thread, cluster or subsystem is

added to the system

Object-oriented Testing Strategies(4)

Validation Testing Are we building the right product? Validation succeeds when software functions in a manner that

can be reasonably expected by the customer. Focuses on visible user actions and user recognizable

outputs Validation tests are based on the use-case scenarios, the

object behavior model, and the event flow diagram Apply:

Use-case scenarios from the software requirements spec Black-box testing to create a deficiency list Acceptance tests through alpha (at developer’s site) and beta (at

customer’s site) testing with actual customers

Object-oriented Testing Strategies(5)

Software may be part of a larger system. This often leads to “finger pointing” by other system dev teams

Finger pointing defence:1. Design error-handling paths that test external information2. Conduct a series of tests that simulate bad data3. Record the results of tests to use as evidence

Types of System Testing: Recovery testing: how well and quickly does the system recover from

faults Security testing: verify that protection mechanisms built into the system

will protect from unauthorized access (hackers, disgruntled employees, fraudsters)

Stress testing: place abnormal load on the system Performance testing: investigate the run-time performance within the

context of an integrated system

Test Case Design(1)

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

the purpose of the test should be stated A list of testing steps should be developed for each test and

contains: A list of specified states for the object that is to be tested A list of messages and operations that will be exercised as a

consequence of the test A list of exceptions that may occur as the object is tested A list of external conditions needed to be changed for the test Supplementary information required to understand or implement

the test OO testing focuses on designing appropriate sequences of

operations

Testing Methods at the Class Level(1)

Random Testing : requires large number of data permutation and combination

Identify operations applicable to a class Define constraints on their use– e.g. the class must always

be initialized first Identify a minimum test sequence – an operation sequence

that defines the minimum life history of the class Generate a variety of random test sequences– this

exercises more complex class instance life histories

Testing Methods at the Class Level(2)

Example of Random Testing

1) consider an account class that has the following operations:

open, setup, deposit, withdrawal, balance, summarize, credit Limit, close

2) The account must be opened first and closed on completion

Testing Methods at the Class Level(3)

Example of Random Testing

3) a variety of behaviors may occur:

open•setup•deposit•[deposit | withdrawal | balance| summarize | credit limit]n•withdrawal•close

4) different operation sequences can be generated randomly:

test case #1: open•setup•deposit•deposit• balance• summarize• withdrawal•close

test case #2: open•setup•deposit•withdrawal• deposit• balance• credit limit•withdrawal•close

Testing Methods at the Class Level(4)

Partition Testing : reduces the number of test cases required to test a class (remember ECP)

Input and output are categorized Deriving partitioning categories:

State-based partitioning Categorizes class operations based on their ability to change the state of

the class Tests designed in way so that operations that cause state changes are

tested separately from those that do not Example: Test case #sp1: open•setup•deposit•deposit• withdrawal•

withdrawal•close Test case #sp2: open•setup•deposit•summarize •credit limit• withdrawal•close

Testing Methods at the Class Level(5)

Deriving partitioning categories: Attribute-based partitioning

Categorizes class operations based on the attributes that they use and modify

Tests designed in way so that operations that use or modify attributes are tested separately from those that do not use or modify attributes

Example:

for the account class, the attributes balance and credit limit can be used to define operations. Operations are divided into three partitions:

1) operations that use credit limit

2) operations that modify credit limit

3) operations that do not use of modify credit limit

Testing Methods at the Class Level(6)

Deriving partitioning categories: Category-based partitioning

Categorizes class operations based on the generic function that each performs such as initialization, computation, query, termination

Example:

operations in the account class can be categorized as:

1) initialization (open, setup)

2) computation (deposit, withdraw)

3) queries (balance, summarize, credit limit)

4) termination (close)

Interclass Test Case Design(1)

Test case design becomes more complicated as integration of the OO system begins – testing of collaboration between classes

Refer to diagram

Interclass Test Case Design(2)

Multiple class testing For each client class, use the list of class operators to generate

a series of random test sequences that send messages to other server classes

For each message generated, determine the collaborator class and the corresponding operator in the server object

For each operator in the server object (invoked by a client object message), determine the message that it transmits

For each of the message, determine the next level of operators that are invoked and incorporate these into the test sequence.

Interclass Test Case Design(3)

Multiple class testing : exampleConsider a sequence of operations for the bank class relative to an ATM class:verifyAcct•verifyPin•[[verifyPolicy•withdrawReq] | depositReq | AcctInfoReq]n

A random test case for the bank class might beTest case #r3: verifyAcct•verifyPin• depositReq

The collaborators invoked for the above test case are ValidationInfo to execute verifyAcct and verifyPin. Collaborate with Account to execute depositReq

Thus a new test case isTest case #r4 :

verifyAcctBank[validAcctValidationInfo]•verifyPinBank•[ValidPinValidationInfo•depositReq•[depositAccount]

Interclass Test Case Design(4)

Test derived from behavior models Use the state transition diagram as a model Test cases must cover all states 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

Testing MethodsApplicable at Interclass Level(1)

Cluster Testing Concerned with integrating and testing clusters of cooperating

objects Identify clusters using knowledge of the operation of objects and

the system features that are implemented by these clusters Approaches to cluster testing

Use-case or scenario testing Testing is based on a user interactions with the system Has the advantage that it tests systems features as experienced by users

Thread testing – tests the systems response to events as processing threads through the system

Object interaction testing – test sequences of object interactions that stop when an object operation does not call on services from another object

Testing MethodsApplicable at Interclass Level(2)

Use Case/Scenario-based Testing Based on

Use cases Corresponding sequence diagrams

Identify scenarios from use-case and supplement these with interaction diagrams that show the objects involved in the scenario

Concentrates on functional requirements Every use case Every fully expanded (<<extend>>) combination Every fully expanded (<<uses>>) combination Tests normal as well as exceptional behavior

OO Test Design Issues

White-box testing methods can be applied to testing the code used to implement operations

Black-box testing methods are appropriate for testing OO systems

OO programming brings additional testing concerns Classes may contain operations that are inherited from

superclass Subclasses may contain operations that were redefined rather

than inherited All classes derived from a previously tested base class need to

be thoroughly tested.

Summary

One strategy is a bottom-up approach – class, integration, validation and system level testing