Object Oriented Testing

1. Object Oriented Testing

2. object models an entity, thing; has a set of attribute values that define a state of the object has set of operations it is capable of performing to change its attribute values which may cause changes to attribute values of other objects. object has an identity to uniquely identify it - distinguish from other objects having the same attribute values.

3. complex interdependency problem object state behavior testing problem tool support problem

4. Encapsulation - information hiding Inheritance - from super class - object may have more than one super class methods inherited from a superclass must be retested in the context of the subclass, because testing using the context of the superclass may not include all the cases that may occur in context of the subclass. Polymorphism - take on multiple forms - attribute have more than one set of values and an operation may be implemented by more than one method. Ex - move differs if chess or checkers

5. Dynamic binding - methods that implement an operation are unknown until run time. The choice of which implementation to use when an operation is invoked is determined at run time according to the types, the number of arguments, and/or the function- context of usage.

6. Object Oriented Testing & Maintenance Problems understanding problem complex interdependency problem object state behavior testing problem tool support problem

7. The Understanding Problem: Introduced by encapsulation; several member functions from possibly several object classes are invoked to achieve an intended functionality. Often a member fct of a class in turn invokes other member fcts, resulting in so-called invocation chains of member fcts. Example shows very long chains - implication of the invocation chains is that a tester/maintainer has to understand sequences of member fcts and the semantics of the classes prior to preparing any test cases and/or modifying any fct. Look at table 1.

8. THE COMPLEX DEPENDENCY PROBLEM: In OO programs that include inheritance, aggregation, association, template class instantiation, class nesting, dynamic object creation, member function invocation, polymorphism and dynamic binding relationships complexity is readily found InterView 122 classes, 400 inheritance, aggregation and assoc. relationships - more than 1k member fcts.

10. It is very difficult to understand a given class in a large OO program if that class depends on many other classes Without sufficient insight, a tester may not know where to start in testing an OO library. Extremely costly to construct stubs, tester must understand called fcts, possibly create and properly initialize certain objects, and write code to simulate the behaviors and effects of the called fcts. Impossible to predict and equally impossible to test, all possible uses of a template class

11. Difficult to identify and test the effect of polymorphism and dynamic binding Difficult to id change impact in OO maintenance, since the impact may ripple throughout the OO program through the complex dependencies.

12. STATE BEHAVIOR TESTING PROBLEM Objects have states and state dependent behaviors. So we need an object state diagram and generate associated tests. Effect of an operation on an object depends of the state of the object and may change the state of the object. Thus the combined effect of the operations must be tested. OO state behavior testing can be specification based or program based. Documentation is either missing or poor - use a program based approach.

13. Derive from the source code the state-dependent behaviors of the objects and represent this info in an OSD; generate test cases and test data from the OSD to test the program and observe the output.

14. THE TOOL SUPPORT PROBLEM CASE tools still in infancy that support OO testing; sw testing tedious - preparation, execution, analysis of tens of thousands of cases and test data sets. could use a spec based approach; derived from specs; required formal specs so tool can derive test cases - depends on level of detail of formal spec - observation of authors formal specs rarely used ( at least in this country) tester must manually prepare; does need extensive tool support

15. OOTM ENVIRONMENT math defined test model with three diagrams: 1) object relation diagram - std stuff of oo model 2) block branch diagram - shows control structure of a member fct; interfaces to other member fcts; therefore tester knows which data is used and/or updated and which other fcts are invoked by the member fct. BBD diagram helps prepare fct test cases, structural test cases, test harnesses in member fct unit testing, derive data dependence across multiple fcts and objects; and display statement, branch, and path coverage information.

16. 3) OSD - object state diagram similar to Statechart - show state behavior of an object; reduce complexity for each state-dependent data member of a class; so state behavior of class is aggregate of the data members� state machines so have hierarchy of state machines - remember - what does a hierarchy do for us?

17. � For maintenance in fixing errors: The firewall tool automatically identifies changes and computes the affected classes; displays the test order for retesting the affected classes. So firewall tool used in two different ways: before making actual changes to id impact of changes; estimate effort in terms of test stubs and test cases needed to retest the affected classes after making changes, a regression tester can use the tool to identify the actual changes and their impact. also compute the optimal test order to retest the affected classes.

18. OOTM OSD consists of hierarchical, concurrent, communicating state machines. Supports inheritance and aggregation features; concurrent because objects viewed as concurrent processes and communicating because objects can send and receive messages from each other.