Testing Object-Oriented Software

• State dependent behavior

• Encapsulation

• Inheritance

• Polymorphism and dynamic binding

• Abstract and generic classes

• Exception handling

• State-based testing

• Testing with state machines

• Testing with inheritance

• Testing with polymorphism

• Testing exception handlers

• Classes -> state/instance variables

• Functions -> operations/methosd

• States:

  • Concrete: Attribute valuations

    • E.g.: number = 42 && list = ['a', 'b', 'c'], etc.

  • Abstract: Predicates over attribute valuations (state invariants)

    • E.g.: positive ↔ number >= 0

• Basic Idea:

  • Interpret code as EFSM (extended finite state machines)

  • check certain fault models

• One variant of model-based testing

• Incorrect initialization

• Inadvertent bindings (multiple inheritance; missing override)

• Naked access (access of instance variable instead of getter/setter)

• Incorrect location of subclass: (e.g. class rectangle instead of square used)

• Conflict subclass and superclass (e.g. incorrect override)

• Naughty children (leaves object in state that is illegal in superclass)

• Worm holes (subclass computes values inconsistent with superclass)

• Spaghetti inheritance (deep hierarchies are error prone)

  
  

• Flattening:

  • Inheritance implemented by mechanims: Extension, Overriding, Specialization

  • Makes all inhereted features explicit

• Test Reuse:

  • partially reuse for overritten methods

  • no test for inherited methods

  • new test for new methods

Liskov’s substitution principle: Objects of superclass should be replaceable by objects of subclass without breaking the application

• Polymorphic server test

  • intention: conformance with liskov’s substition principle

  • fault models: all inhericance fault models

  • server-related faults only

• Model Hierarchy Test

  • intention: flattened class scope with constraints on sequencing methods

• Polymorphic Message Test

  • intention: test client of a polymorphic server

  • all possible bindings of each polymorphic message must be exercised once

Test each exception handler, and each explicit throw or re-throw of an exception

• Local exception handlers:

  • Test the exception handler

• Non-local exception handler:

  • difficult to determine all pairings of <points, handler>

  • enforce design rule: if method propagates exception -> method call should have no other effect

• Missing or incorrect transition or event

  • Resulting state is incorrect yet not corrupt

• Missing or incorrect action

  • Wrong thing happens when executing a transition

• Extra, missing, or corrupt state

  • Behavior becomes unpredictable

• Sneak path or illegal message failure

  • Message accepted when it shouldn’t or unexpected message causes a failure

• State Coverage: Cover all states

• Transition Coverage: Cover all transitions

• Transition path coverage: Cover all possible paths