November 13, 2006ECEN 5543 / CSCI 5548 – Testing OO University of Colorado, Boulder 1 Testing Object-Oriented Software Principles Summary ECEN 5543 / CSCI 5548 SW Eng of Standalone Programs University of Colorado, Boulder

November 13, 2006ECEN 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.

November 13, 2006ECEN 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

November 13, 2006ECEN 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

November 13, 2006ECEN 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 components of 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

November 13, 2006ECEN 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

November 13, 2006ECEN 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

November 13, 2006ECEN 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.

November 13, 2006ECEN 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.”

November 13, 2006ECEN 5543 / CSCI 5548 – Testing OO University of Colorado, Boulder 10 Outline Objects Objects from a testing perspective Messages Messages from a testing perspective Interfaces Interfaces from a testing perspective Operations Operations from a testing perspective 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

November 13, 2006ECEN 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

November 13, 2006ECEN 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

November 13, 2006ECEN 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

November 13, 2006ECEN 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

November 13, 2006ECEN 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

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

November 13, 2006ECEN 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.

November 13, 2006ECEN 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

November 13, 2006ECEN 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

November 13, 2006ECEN 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.

November 13, 2006ECEN 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

November 13, 2006ECEN 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

November 13, 2006ECEN 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)

November 13, 2006ECEN 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 of data 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.

November 13, 2006ECEN 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

November 13, 2006ECEN 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

November 13, 2006ECEN 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 Behavior of 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

November 13, 2006ECEN 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

November 13, 2006ECEN 5543 / CSCI 5548 – Testing OO University of Colorado, Boulder 29 Substitution Principle of Inheritance from 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 add transitions 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

November 13, 2006ECEN 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

November 13, 2006ECEN 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

November 13, 2006ECEN 5543 / CSCI 5548 – Testing OO University of Colorado, Boulder 32