november 13, 2006ecen 5543 / csci 5548 – testing oo university of colorado, boulder 1 testing...
Post on 20-Dec-2015
217 Views
Preview:
TRANSCRIPT
November 13, 2006 ECEN 5543 / CSCI 5548 – Testing OOUniversity 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, 2006 ECEN 5543 / CSCI 5548 – Testing OOUniversity 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, 2006 ECEN 5543 / CSCI 5548 – Testing OOUniversity 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, 2006 ECEN 5543 / CSCI 5548 – Testing OOUniversity 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, 2006 ECEN 5543 / CSCI 5548 – Testing OOUniversity 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, 2006 ECEN 5543 / CSCI 5548 – Testing OOUniversity 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, 2006 ECEN 5543 / CSCI 5548 – Testing OOUniversity 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, 2006 ECEN 5543 / CSCI 5548 – Testing OOUniversity 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, 2006 ECEN 5543 / CSCI 5548 – Testing OOUniversity 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, 2006 ECEN 5543 / CSCI 5548 – Testing OOUniversity 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, 2006 ECEN 5543 / CSCI 5548 – Testing OOUniversity 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, 2006 ECEN 5543 / CSCI 5548 – Testing OOUniversity 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, 2006 ECEN 5543 / CSCI 5548 – Testing OOUniversity 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, 2006 ECEN 5543 / CSCI 5548 – Testing OOUniversity 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, 2006 ECEN 5543 / CSCI 5548 – Testing OOUniversity 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, 2006 ECEN 5543 / CSCI 5548 – Testing OOUniversity of Colorado, Boulder
16
Basic terms
ClassA
SubClassA1 SubClassA2
November 13, 2006 ECEN 5543 / CSCI 5548 – Testing OOUniversity 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, 2006 ECEN 5543 / CSCI 5548 – Testing OOUniversity 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, 2006 ECEN 5543 / CSCI 5548 – Testing OOUniversity 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, 2006 ECEN 5543 / CSCI 5548 – Testing OOUniversity 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, 2006 ECEN 5543 / CSCI 5548 – Testing OOUniversity 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, 2006 ECEN 5543 / CSCI 5548 – Testing OOUniversity 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, 2006 ECEN 5543 / CSCI 5548 – Testing OOUniversity 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, 2006 ECEN 5543 / CSCI 5548 – Testing OOUniversity 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, 2006 ECEN 5543 / CSCI 5548 – Testing OOUniversity 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, 2006 ECEN 5543 / CSCI 5548 – Testing OOUniversity 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, 2006 ECEN 5543 / CSCI 5548 – Testing OOUniversity 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, 2006 ECEN 5543 / CSCI 5548 – Testing OOUniversity 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, 2006 ECEN 5543 / CSCI 5548 – Testing OOUniversity 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 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, 2006 ECEN 5543 / CSCI 5548 – Testing OOUniversity 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, 2006 ECEN 5543 / CSCI 5548 – Testing OOUniversity 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, 2006 ECEN 5543 / CSCI 5548 – Testing OOUniversity of Colorado, Boulder
32
top related