Testing Object-Oriented Software Principles Summary

1. Testing Object-Oriented SoftwarePrinciples Summary ECEN 5543 / CSCI 5548 SW Eng of Standalone Programs University of Colorado, Boulder ECEN 5543 / CSCI 5548 – Testing OO University of Colorado, Boulder

2. Testing vs. Quality Assurance • Quality Assurance • Responsible for test plans and system testing • Monitor testing during development • Keep statistics • Testing is a necessary but insufficient part of a QA process • QA addresses activities designed to • prevent defects • remove defects • Testing helps in identifying problems and failures • Testing helps QA by identifying them early in dev. ECEN 5543 / CSCI 5548 – Testing OO University of Colorado, Boulder

3. What’s special about testing OO software? • Features such as class inheritance and interfaces support polymorphism in which code manipulates objects without their exact class being known • Testers must ensure the code works no matter what the exact class of such objects might be. • Features that support data hiding complicate testing because operations must be added to a class interface (by the developer) just to support testing ECEN 5543 / CSCI 5548 – Testing OO University of Colorado, Boulder

4. OO Testing Is Still Testing • We still do • unit testing but we change the definition of unit • integration testing to make sure subsystems work correctly together • system testing to verify that requirements are met • regression testing to make sure previous functionality still works after new functionality is added ECEN 5543 / CSCI 5548 – Testing OO University of Colorado, Boulder

5. OO Testing Is Not Just Old Style Testing • Fundamental aspect of OO software • OO Software is designed as a set of objects that essentially model a problem and then collaborate to effect a solution • While the solution may change over time, the structure and componentsof the problem do not change as frequently • a program structured from the problem is more adaptable to changes later • components derived from the problem can be reused in development of other programs to solve related problems ECEN 5543 / CSCI 5548 – Testing OO University of Colorado, Boulder

6. Benefit • Many analysis models map straightforwardly to design models which, in turn, map to code • Start testing during analysis • Refine the same tests for design • Refine those tests for code ECEN 5543 / CSCI 5548 – Testing OO University of Colorado, Boulder

7. Advantages of testing analysis and design models • Test cases can be identified earlier in the process, even while determining requirements • Early test cases help analysts and designers to • better understand and express requirements • ensure that specified requirements are testable • Bugs can be found early – saving time and money • Test cases can be reviewed for correctness early in the project • If test cases are applied to models early, misunderstandings of requirements on the part of testers can be corrected early ECEN 5543 / CSCI 5548 – Testing OO University of Colorado, Boulder

8. Categories of OO Testing • Model testing • Class testing instead of unit testing • Class interaction testing instead of integration testing • System and subsystem testing • Acceptance testing • Self-testing • Should you try to apply all of these? Probably not if you want to be taken seriously and be employed. • You should learn to recognize approaches and techniques that will apply to your project in a useful and affordable way. ECEN 5543 / CSCI 5548 – Testing OO University of Colorado, Boulder

9. Testing perspective • Skeptical, objective, thorough, systematic • Look at any development product and question its validity • Attitude that should be held by a developer as well as a full-time tester • To ensure • a. the software will do what it is supposed to do • b. the software will not do what it is not supposed to do • Ensuring “a.” does not automatically ensure “b.” ECEN 5543 / CSCI 5548 – Testing OO University of Colorado, Boulder

10. Outline • Classes • Classes from a testing perspective • Inheritance from a testing perspective • Substitution principle • Substitution principle from a testing perspective • Abstraction • Abstraction from a testing perspective • Objects • Objects from a testing perspective • Messages • Messages from a testing perspective • Interfaces • Interfaces from a testing perspective • Operations • Operations from a testing perspective ECEN 5543 / CSCI 5548 – Testing OO University of Colorado, Boulder

11. Object • An operational entity that encapsulates both specific data values and the code that manipulates those values. • Provides the mechanisms needed to • receive messages • dispatch methods • return results • associate instance attributes with methods ECEN 5543 / CSCI 5548 – Testing OO University of Colorado, Boulder

12. Objects from a testing perspective • Encapsulates – the complete definition of the object is easy to identify, easy to pass around, easy to manipulate • Hides information – can make changes to the object hard to observe which makes checking test results difficult • Has a state that persists for its life. This state can become inconsistent and can be the source of incorrect behavior • Has a lifetime – can be examined during its lifetime to check if it is in the right state based on its lifetime. • Common source of failures – construction of an object too late or destruction of it too early ECEN 5543 / CSCI 5548 – Testing OO University of Colorado, Boulder

13. Message • Message – a request that an operation be performed by some object. • can include actual parameters used to perform that operation • receiver can return a value • OO program is a community of objects that collaborate to solve a problem. • This is achieved by sending messages to one another • Can result in a return value • Can result in an exception from receiver to sender ECEN 5543 / CSCI 5548 – Testing OO University of Colorado, Boulder

14. Messages from a testing perspective • A message • has a sender who determines when to send and may make an incorrect decision about this • has a receiver • may not be ready for the specific msg it receives • may not take the correct action if msg if unexpected • may include actual parameters • used by or updated by the receiver • objects passed as parameters must • be in correct states before and after the msg is processed • implement the interfaces expected by the receiver ECEN 5543 / CSCI 5548 – Testing OO University of Colorado, Boulder

15. Interfaces from a testing perspective • Interface encapsulates operation specifications which • build the specifications of larger groupings such as classes • If it contains behaviors that do not belong with the other behaviors, implementations of the interface will have unsatisfactory designs • Interface has relationships with other interfaces and classes. • may be specified as the parameter type for a behavior to allow any implementer of that interface to be passed as a parameter • Interface describes a set of behavior declarations whether or not we use the interface syntax ECEN 5543 / CSCI 5548 – Testing OO University of Colorado, Boulder

16. Basic terms ClassA SubClassA1 SubClassA2 ECEN 5543 / CSCI 5548 – Testing OO University of Colorado, Boulder

17. Operations • A class specification includes a specification for each of the operations that can be performed by each of its instances • An operation is an action that can be applied to an object to obtain a certain effect. • Accessor (inspector) operations – provide information about the object but do not change the object • Modifier (mutator) operations – change the state of the object by setting one or more attributes to have new values (perhaps not every time) • Accessors are tested differently than modifiers. ECEN 5543 / CSCI 5548 – Testing OO University of Colorado, Boulder

18. Two special operations • Constructor – a class object operation used to create a new object • includes initializing a new instance when it comes into existence • Destructor – an instance object operation used to perform any processing needed just prior to the end of the object’s lifetime • Differ from accessors & modifiers • invoked implicitly as a result of the birth and death of objects ECEN 5543 / CSCI 5548 – Testing OO University of Colorado, Boulder

19. What do we expect of a class specification? • A description of what a class represents. It’s either a concept • in the problem being solved or • in the solution to that problem • Some meaning and constraints to be associated with each of the operations defined in the class specification • So ... each operation should have a specification that describes what it does, including its preconditions and invariants ECEN 5543 / CSCI 5548 – Testing OO University of Colorado, Boulder

20. Reminder • Preconditions • Conditions that must hold before the operation can be invoked. • Post conditions • Conditions that must hold after the operation is performed. Guaranteed. • Invariants • Conditions that must always hold within the lifetime of the object • An operation’s method may violate invariants during execution but it must “hold again” by completion. ECEN 5543 / CSCI 5548 – Testing OO University of Colorado, Boulder

21. To write a specification for an operation • To define the interface between the receiver and the sender • Contract approach – emphasizes preconditions but has simpler post conditions • Defensive programming approach -- emphasizes post conditions but has simpler preconditions and ... more parameter testing ECEN 5543 / CSCI 5548 – Testing OO University of Colorado, Boulder

22. What does this mean for tester? • The approach used in an interface determines the types of testing that need to be done. • Contract approach • simplifies class testing • complicates interaction testing – must ensure any sender meets the preconditions • Defensive approach • complicates class testing – test cases must address all possible outcomes • complicates interaction testing – must ensure all possible outcomes are produced and that they are properly handled by the sender ECEN 5543 / CSCI 5548 – Testing OO University of Colorado, Boulder

23. During design and design inspections of a class – how maintain testing perspective? • Review the preconditions and post conditions for testability • Are the constraints clearly stated? • Does the specification include the means by which one can check preconditions? (the sender does not want to be an expert on the receiver; receiver should explain how to check for the preconditions) ECEN 5543 / CSCI 5548 – Testing OO University of Colorado, Boulder

24. Class implementation • Describes how an object represents its attributes and carries out its operations. It is made of several components: • A set ofdata values stored in data members (aka instance variables or variables) – some or all of the values associated with the attributes of an object. • A set of methods (aka member functions) – code used to implement an algorithm to accomplish an operation declared in the public or private class specification. • A set of constructors to initialize a new instance. • A destructor to handle any processing associated with destruction of an instance • A set of private operations in a private interface – provide support for the implementation of public operations. ECEN 5543 / CSCI 5548 – Testing OO University of Colorado, Boulder

25. Classes from a testing perspective • A class specification contains operations to construct instances. They may not properly initialize the attributes of new instances. • Class relies on collaboration to define its behaviors and attributes. The other classes may be implemented incorrectly and contribute to failure of the class that relies on them. • A class’ implementation “satisfies” its specification – does not mean the specification is correct. • Might not support all required operations; may perform them incorrectly. • Might not provide a way for a precondition to be checked by a sender before sending a message ECEN 5543 / CSCI 5548 – Testing OO University of Colorado, Boulder

26. Inheritance from a testing perspective • Provides a mechanism by which bugs can be propagated from a class to each of its descendants  • Important reason to test classes as they are developed to eliminate fault propagation • Provides a mechanism by which we can reuse test cases. • subclass inherits part of its specification and implementation from its superclass, potentially can reuse test cases from superclass to subclass • Models an is-a-kind-of relationship • Use of inheritance solely for code reuse will probably lead to maintenance difficulties • Common mistake in OO development ECEN 5543 / CSCI 5548 – Testing OO University of Colorado, Boulder

27. Inheritance models is-a-kind-of relationship • If D is a subclass of C, then D is a kind of C • If so, an instance of D can be used whenever an instance of C is expected • To work, the behavior of D must somehow conform to that which is associated with C • Behaviorof a class • observable states of an instance • the semantics associated with the operations defined for an instance of that class • Behavior of a subclass – incremental changes to the observable states and operations defined by its superclass ECEN 5543 / CSCI 5548 – Testing OO University of Colorado, Boulder

28. Substitution Principle • Only the following changes are allowed in defining the behavior associated with a new subclass: • Preconditions for each operation must be the same or weaker – less constraining – than those of the superclass • Post conditions for each operation must be the same or stronger – do at least as much as defined by the superclass • Class invariant – must be the same or stronger; add more constraints ECEN 5543 / CSCI 5548 – Testing OO University of Colorado, Boulder

29. Substitution Principle of Inheritancefrom a testing perspective • Developers must enforce (in inspections, if not before) the constraints of this principle on behavior changes • Observable states and all transitions between them associated with the superclass must be preserved by the subclass • The subclass may addtransitions between these states • The subclass may add observable states as long as each is either concurrent or a substate of an existing state • In other words, don’t use inheritance because you are too lazy to specify a class that is similar but is-not-a-kind-of ECEN 5543 / CSCI 5548 – Testing OO University of Colorado, Boulder

30. Abstraction • The process of removing detail from a representation. • Allows us to look at a problem in various levels of detail. • leave out details that are irrelevant for a given consideration • OO technologies use abstraction extensively • inheritance hierarchy, for example • system models whose detail increases during development ECEN 5543 / CSCI 5548 – Testing OO University of Colorado, Boulder

31. Layers of abstraction from a testing perspective • Layers of abstraction in the development process are paralleled by layers of testing analysis • If we begin testing analysis with the highest levels of abstraction of development models, • we provide a more thorough examination of the development product • and, therefore, a more effective and accurate set of tests ECEN 5543 / CSCI 5548 – Testing OO University of Colorado, Boulder

32. ECEN 5543 / CSCI 5548 – Testing OO University of Colorado, Boulder