1 Software Testing and Quality Assurance Lecture 11 - The Testing Perspective (Chapter 2, A...

1

Software Testing and Quality Assurance

Lecture 11 - The Testing Perspective (Chapter 2, A Practical Guide to

Testing Object-Oriented Software)

2

Lecture Outline Testing perspective -Object-Oriented

Concepts Interface Class

3

Interface - Testing Perspective An interface is an aggregation of

behavioral declarations. An interface is a building block for

specifications. In java: interface In C++: by declaring abstract class with

only public, pure virtual methods.

4

Interface - Testing Perspective Interface encapsulates operation

specifications. Theses specifications incrementally build the

specifications of large groupings such as classes. Interface has relationships with other

interfaces and classes. Testers perspective:

Relationship between interfaces.

5

Interface - Testing Perspective- Example For example, an interface might

describe a set of behaviors related to being a moving object.

public interface Movable {public Point getsPosition ():

public Velocity getVelocity();public void mover();

}

6

Class - Testing Perspective A class is a set of objects that share a

common conceptual bases (a template for creating objects). Objects form the basic element for

executing OO programs While classes form the basic elements for

defining OO programs.

7

Class - Testing Perspective Instantiation: the process of creating an

object. Instance (object): the result of instantiation. The conceptual basis common to all the

objects in a class is expressed in terms: A class specification: what each object can do (C+

+ header file). A class implementation: how each object do what

they can do.

8

Class Specifications Describes what the class represents and what an instance of the class can do.

An operation is an action that can be applied to an object to obtain a certain effect: Accessor (or inspector) operation: provide

information about an object. For example, value of some attribute (in C++, const)

Modifier operations: change the state of an object by setting one or more attributes to have new values.

Class Specifications

9

Class Specifications Other types of operations:

A constructor is a class object operation used to create a new object including the initialization of the new instance when it comes into existence.

A destructor is an instance object operation used to perform any processing needed just prior to the end of an object’s lifetime.

10

Class Specifications Semantics can be specified at several

different points: Preconditions: conditions that must hold before

the operation is performed. Postconditions: conditions that must hold after

the operation is performed. Invariants: conditions that must always hold

within the life time of the object. Implied post-condition for each operation.

Testers care about Preconditions, post-conditions, invariants Relation to other classes (interactions)

11

Class Specifications To write specification for an operation, two

basic approaches can be used to define the interface between the receiver and the sender: Design by contract approach. Defensive programming approach.

Each approach has a set of rules about how to define the constraints and the responsibilities for the sender and receiver when an operation to be performed.

12

Class Specifications - Contract Design by contract:

A contract between the sender and receiver of a message.

The sender is responsible for ensuring the preconditions are met.

The receiver is responsible for ensuring post-conditions are met and maintaining class invariants.

Testers care about how this contract is enforced. Language support:

iContract

13

Class Specifications - Contract Pre and Postcondition - Summary

Client (i.e. caller) Supplier (i.e. method)

Obligation Must ensure precondition (i.e. correct input parameter)

Must ensure post-condition (i.e. method works correctly)

Benefit Need not ensure post-condition (i.e. special values or exceptions

Need not ensure precondition (i.e. validity of input parameters), although it needs to check it before it runs.

14

Class Specifications - Contract

Class B

m(x);

contractClass A

pre: p post: q

Class B says to its clients:

“If you promise to call m with p satisfied, then I, in return, promise to deliver a final

state in which q is satisfied.”

q binds the supplier B. It is an obligation for B

but a benefit for A.

p binds the client A. It is an obligation for A but a benefit for B.

15

Class Specifications - Contract

Design by contract example:

The same example using iContract syntax:

double sqrt (double x)require

x >= 0do

…ensure

result * result == xend

//** return Square root of x @pre x >= 0 @post return * return == x */ double sqrt (double x) { … }

16

Interface is defined primarily in terms of the receiver.

An operation returns some indication concerning the status of the result of the request (success or failure) in terms of return code.

The receiver can provide the sender an object that encapsulates the status of the request. Exceptions are used frequently.

Defensive programming

17

Defensive programming The goal is to identify “garbage in” and

hence eliminate “garbage out”. A member function checks for the

improper values coming in and then report that status of the request to the sender.

18

Defensive programming This approach increases the complexity

of the software. Each sender must follow a request for an

operation with code to check the processing status and then;

for each possible outcome, provide code to take an appropriate recovery action.

Testers care about how the receiver ensures pre and post-conditions.

19

Defensive programming

Defensive programming example using assert:

void test( int *p ) { assert( p != 0 ); if (p == 0)

return; // use p.

}

20

Class Specifications Contract vs. defensive programming:

The contract approach simplifies class testing, but complicates interaction testing because we must ensure any sender meets preconditions.

The defensive programming approach complicates both

class testing (test cases must address all possible outcomes); and

interaction testing (we must ensure all possible outcomes are produced and that they are properly handled by a sender).

21

Class Implementation Class implementation describes how an

object represents its attributes and carries out operations.

It compromises several components: A set of data values stored in data members

(instance variables or variables). A set of methods (member functions in C++ or

methods in Java) constitutes code that will be used to implement an algorithm that accomplishes one operation declared in the public or private class specification.

22

Class Implementation – Testing Perspective From testing perspective, potential causes of failures within

class design and implementation: A class specification contains operations to construct instances.

These operations may not properly initialize the attributes of the new instances.

A class relies on collaboration with other classes to define its behaviors and attributes. These other classes may be implemented incorrectly.

A class’ implementation “satisfies” its specification, but that is no guarantee that the specification is correct.

The implementation might not support all required operations or may incorrectly perform operations.

A class specifies preconditions to each operation. The class may not provide a way for the precondition to be checked by a sender before sending a message.

23

Class Implementation

The design approach used gives rise to different sets of potential problems: In contract approach we only need to test

situations in which the precordinations are satisfied.

In defensive programming approach we must test every possible input to determine that the outcome is handled properly.

24

Key points Object-oriented concepts:

interface class (specification and

implementation)

25

Announcements Help Session

Wednesday or Thursday What time is suitable for everyone?

Major 1 on Sat November 8, 2008 What time is suitable for everyone?