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 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.

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
p binds the client A. It is an obligation for A but a benefit for B.
q binds the supplier B. It is an obligation for B but a benefit for A.
Class B
m(x);
contract
Class 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.”

15. Class Specifications - Contract
double sqrt (double x)
require
x >= 0 do …
ensure
result * result == x
end
Design by contract example:
The same example using iContract syntax:
//** return Square root of x
@pre x >= 0
@post return * return == x */
double sqrt (double x) { … }

16. Defensive programming
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.

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 Major 1 on Sat November 8, 2008
Wednesday or Thursday
What time is suitable for everyone?
Major 1 on Sat November 8, 2008