Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Scribd Logo
Upload

Welcome to Scribd!

  • 150 views

    Issues in OO Testing

    Uploaded by

    Suresh Popz
    This document discusses issues and challenges with object-oriented (OO) testing. It notes that while OO was intended to promote code reuse, consensus is that OO programs have more severe testing problems than traditional programs. Key challenges include determining what constitutes a testable "unit", complications introduced by OO concepts like inheritance and polymorphism, and determining appropriate levels of testing. It explores approaches like defining units as single-developer components or compilable/executable components, and extending traditional testing techniques to address encapsulation, composition and other OO aspects.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd

    Issues in OO Testing

    Uploaded by

    Suresh Popz
    150 views15 pages
    This document discusses issues and challenges with object-oriented (OO) testing. It notes that while OO was intended to promote code reuse, consensus is that OO programs have more severe testing problems than traditional programs. Key challenges include determining what constitutes a testable "unit", complications introduced by OO concepts like inheritance and polymorphism, and determining appropriate levels of testing. It explores approaches like defining units as single-developer components or compilable/executable components, and extending traditional testing techniques to address encapsulation, composition and other OO aspects.

    Original Description:

    Abcd

    Original Title

    1

    Copyright

    © © All Rights Reserved

    Available Formats

    PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    This document discusses issues and challenges with object-oriented (OO) testing. It notes that while OO was intended to promote code reuse, consensus is that OO programs have more severe testing problems than traditional programs. Key challenges include determining what constitutes a testable "unit", complications introduced by OO concepts like inheritance and polymorphism, and determining appropriate levels of testing. It explores approaches like defining units as single-developer components or compilable/executable components, and extending traditional testing techniques to address encapsulation, composition and other OO aspects.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    150 views15 pages

    Issues in OO Testing

    Uploaded by

    Suresh Popz
    This document discusses issues and challenges with object-oriented (OO) testing. It notes that while OO was intended to promote code reuse, consensus is that OO programs have more severe testing problems than traditional programs. Key challenges include determining what constitutes a testable "unit", complications introduced by OO concepts like inheritance and polymorphism, and determining appropriate levels of testing. It explores approaches like defining units as single-developer components or compilable/executable components, and extending traditional testing techniques to address encapsulation, composition and other OO aspects.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    You are on page 1of 15

    Issues in OO Testing

    Chapter 16
    OO context

     OO based on hope that objects could be reused without


     Modification
     Additional testing
     Based on notion that objects encapsulate functions and

    data that belong together


     Consensus now is that such optimism is unwarranted
     OO programs has more severe testing problems than
    traditional programs
     Looking to other models that can be combined with OO to
    ameliorate the problems
     Aspect-oriented programs
     Aspect-orientation can be combined with any

    programming language

    ISS–2
    Problems to address

     Levels of testing
     What is a unit?
     Implications of composition strategy of OO
     Compare to functional decomposition
     OO programs
     Inheritance, encapsulation and polymorphism

     How can traditional testing be extended?

    ISS–3
    OO unit

     Two definitions
     A unit is the smallest program component that can be
    compiled and executed
     A unit is a program component that would be developed by
    one person
     Could be a sub-part of one class

    ISS–4
    Unit is 1-person development

     Traditional testing works well


     Shifts much of the burden of testing to the integration level
     Does not take encapsulation into account
     Know about themselves
     Operate on their own

    ISS–5
    Unit is compilable & executable

     Can describe behaviour


     Model with FSM – Statechart
     Very useful for identifying test cases
     Integration testing is easier
     Integrate by combining already tested classes
     Similar to traditional testing

    ISS–6
    Composition & Encapsulation

     A class may be combined with other unknown classes


     Goal of reuse
     Need high cohesion, low coupling
     Need very good unit testing
     Reality is that burden of testing is still on integration testing

    ISS–7
    SWW– SSD 1

    System Specification Diagram

    All communication channels are Low coupling


    data stream between Wiper
    Lever and Dial
    Channel P is a rough merge of the
    data streams from Lever and Dial

    ISS–8
    SWW– SSD 2

    Channel DL is a High coupling


    statevector read between Lever and Dial
    of Dial by Lever
    When does Lever read DL?

    ISS–9
    SWW – SSD 3

    High coupling between


    When does Wiper read
    Wiper and Lever
    LW and DW?
    Wiper and Dial

    ISS–10
    Complication of inheritance

     Unit is more difficult to define when inheritance is involved


     Suggestion is to use the flat definition
     Becomes complicated with multiple inheritance

     Flattening solves inheritance problem


     Flattened classes are not a part of the system
     Cannot be certain properly tested

     May not have necessary methods for testing


     Can add test methods
     Should they be a part of the delivered system?

     Analogous to having instrumented program text

     Test methods need to be tested …

    See Figures 16.2 & 16.3

    ISS–11
    Complication of polymorphism

     Testing with different objects


     Redundant tests on inherited methods
     Lose hoped for economies

     Similarly testing polymorphism introduces redundant testing

    ISS–12
    Levels of testing – 1

     Individual methods are units


     Four levels
     Method

     Unit testing

     Class

     Intraclass integration testing

     Integration

     Interclass integration testing

     System

     At port level – same as traditional testing

    ISS–13
    Levels of testing – 2

     Classes are units


     Three levels
     Class

     Unit testing

     Integration

     Interclass testing

     System

     At port level

    ISS–14
    Dataflow testing

     Need analogue to dataflow testing of units in traditional


    programs
     Use a revised Petri net definition to handle method calls
    between classes

    ISS–15

    You might also like