Learning objectives Understand how object orientation impacts - PowerPoint PPT Presentation

Learning objectives • � Understand how object orientation impacts software testing � What characteristics matter? – Why? Testing Object Oriented Software – � What adaptations are needed? • � Understand basic techniques to cope with each key characteristic Chapter 15 • � Understand staging of unit and integration testing for OO software (intra-class and inter- class testing) (c) 2008 Mauro Pezzè & Michal Young Ch 15, slide 2 15.2 Characteristics of OO Software Quality activities and OO SW Typical OO software characteristics that impact Actual Needs and Delivered testing User Acceptance (alpha, beta test ) Constraints Package • � S tate dependent behavior Review • � Encapsulation System System Test System Specifications Integration Analysis / • � Inheritance Review • � Polymorphism and dynamic binding Subsystem Integration Test Subsystem Design/Specs • � Abstract and generic classes Analysis / Review • � Exception handling Unit/ Unit/ Component Module Test Components Specs User review of external behavior as it is determined or becomes visible (c) 2008 Mauro Pezzè & Michal Young Ch 15, slide 3 (c) 2008 Mauro Pezzè & Michal Young Ch 15, slide 4

15.3 OO definitions of unit and integration Orthogonal approach: Stages testing • � Procedural software – � unit = single program, function, or procedure more often: a unit of work that may correspond to one or more intertwined functions or programs • � Object oriented software – � unit = class or (small) cluster of strongly related classes (e.g., sets of Java classes that correspond to exceptions) – � unit testing = intra-class testing – � integration testing = inter-class testing (cluster of classes) – � dealing with single methods separately is usually too expensive (complex scaffolding), so methods are usually tested in the context of the class they belong to (c) 2008 Mauro Pezzè & Michal Young Ch 15, slide 5 (c) 2008 Mauro Pezzè & Michal Young Ch 15, slide 6 15.4/5 Intraclass State Machine Testing Informal state-full specifications Slot : represents a slot of a computer model. • � Basic idea: .... slots can be bound or unbound. Bound slots are � The state of an object is modified by operations – assigned a compatible component, unbound slots are � Methods can be modeled as state transitions – empty. Class slot offers the following services: – � Test cases are sequences of method calls that • � Install : slots can be installed on a model as required or traverse the state machine model optional . ... • � S tate machine model can be derived from • � Bind : slots can be bound to a compatible component. specification (functional testing), code ... (structural testing), or both • � Unbind : bound slots can be unbound by removing the bound component. • � IsBound : returns the current binding, if bound; otherwise returns the special value empty . [ Later: Inheritance and dynamic binding ] � (c) 2008 Mauro Pezzè & Michal Young Ch 15, slide 7 (c) 2008 Mauro Pezzè & Michal Young Ch 15, slide 8

Identifying states and transitions Deriving an FSM and test cases • � From the informal specification we can identify isBound incorporate three states: unBind 0 1 2 � Not_installed – Not present Unbound Bound isBound – � Unbound bind – � Bound unBind • � and four transitions � install: from Not_installed to Unbound – • � TC-1: incorporate, isBound, bind, isBound – � bind: from Unbound to Bound • � TC-2: incorporate, unBind, bind, unBind, isBound – � unbind: ...to Unbound � isBound: does not change state – (c) 2008 Mauro Pezzè & Michal Young Ch 15, slide 9 (c) 2008 Mauro Pezzè & Michal Young Ch 15, slide 10 Testing with State Diagrams Statecharts specification class model • � A statechart (called a “ state diagram” in UML) noModelS elected method of � may be produced as part of a specification or super-state or � class Model � selectModel(model) design “OR-state” � _________________ deselectModel() send modelDB: getModel(modelID,this) • � May also be implied by a set of message sequence charts modelS elected (interaction diagrams), or other modeling formalisms addComponent(slot, component) • � Two options: removeComponent(slot) _________________________ workingConfiguration _________________________ send mopdelDB: findComponent() send slot:unbind() � Convert (“ flatten” ) into standard finite-state – send slot:bind() isLegalConfiguration() machine, then derive test cases addComponent(slot, component) [legalConfig = true] removeComponent(slot) _________________________ _________________________ – � Use state diagram model directly send Component_DB: get_component() send slot:unbind() send slot:bind called by � validConfiguration class Model � (c) 2008 Mauro Pezzè & Michal Young Ch 15, slide 11 (c) 2008 Mauro Pezzè & Michal Young Ch 15, slide 12

From Statecharts to FSMs Statechart based criteria • � In some cases, “ flattening” a S tatechart to a noModelS elected finite-state machine may cause “ state explosion” selectModel(model) deselectModel() • � Particularly for super-states with “ history” addComponent(slot, component) • � Alternative: Use the statechart directly workingConfiguration removeComponent(slot) deselectModel() • � S imple transition coverage: isLegalConfiguration() addComponent(slot, component) removeComponent(slot) [legalConfig=true] execute all transitions of the original S tatechart • � incomplete transition coverage of corresponding FS M validConfiguration • � useful for complex statecharts and strong time constraints (combinatorial number of transitions) (c) 2008 Mauro Pezzè & Michal Young Ch 15, slide 13 (c) 2008 Mauro Pezzè & Michal Young Ch 15, slide 14 15.6 Account Customer Order Package Interclass Testing 1 0..* 1 * 1 * * 1 * * USAccount OtherAccount CustomerCare LineItem • � The first level of integration testing for obj ect- oriented software JPAccount EUAccount UKAccount SimpleItem CompositeItem – � Focus on interactions between classes • � Bottom-up integration according to “ depends” * * * * relation Model PriceList Component from a class � A depends on B: Build and test B, then A – * 1 * 1 0..1 * diagram... Slot • � S tart from use/ include hierarchy � Implementation-level parallel to logical “ depends” relation – * 1 1 1 • � Class A makes method calls on class B ModelDB SlotDB ComponentDB • � Class A obj ects include references to class B methods – � but only if reference means “ is part of” CSVdb (c) 2008 Mauro Pezzè & Michal Young Ch 15, slide 15 (c) 2008 Mauro Pezzè & Michal Young Ch 15, slide 16

....to a hierarchy Interactions in Interclass Tests Customer Order Package • � Proceed bottom-up • � Consider all combinations of interactions USAccount OtherAccount � example: a test case for class Order includes a call to – PriceList Component CustomerCare a method of class Model , and the called method calls a method of class S lot, exercise all possible relevant Model states of the different classes JPAccount EUAccount UKAccount ComponentDB – � problem: combinatorial explosion of cases Slot – � so select a subset of interactions: • � arbitrary or random selection Note: we may have ModelDB SlotDB • � plus all significant interaction scenarios that have been to break loops and previously identified in design and analysis: sequence + generate stubs � collaboration diagrams (c) 2008 Mauro Pezzè & Michal Young Ch 15, slide 17 (c) 2008 Mauro Pezzè & Michal Young Ch 15, slide 18 15.7 sequence diagram Using Structural Information O:Order C20:Model ChiMod:ModelDB C20Comp:Compoment C20slot:Slots ChiSlot:SlotDB ChiComp:ComponentDB selectModel() getmodel(C20) • � S tart with functional testing select() � As for procedural software, the specification (formal – extract(C20) or informal) is the first source of information for addCompoment(HD60) testing object-oriented software contains(HD60) found • � “ S pecification” widely construed: Anything from a isCompatible(HD60) requirements document to a design model or detailed incompatible interface description fail • � Then add information from the code (structural addCompoment(HD20) contains(HD20) testing) found � Design and implementation details not available – isCompatible(HD20) from other sources compatible bind success (c) 2008 Mauro Pezzè & Michal Young Ch 15, slide 19 (c) 2008 Mauro Pezzè & Michal Young Ch 15, slide 20