Docstoc

Software Testing and Quality Assurance

Document Sample
Software Testing and Quality Assurance Powered By Docstoc
					Software Testing and Quality
Assurance

    Lecture 28 – Testing Class
           Hierarchies



                                 1
Lecture Objectives
   To know what must be tested in code
    that is inherited.
   To learn how to encapsulate the test
    cases for a specific class using PACT.
   To learn what testing is possible for
    abstract classes.


                                         2
Inheritance in Object-Oriented
development
   Good object-oriented design requires for a
    very disciplined use of inheritance with
    substitution principle.
   Assumption: inheritance has been used in
    accordance with the substitution principle.
   Under this assumption, the set of test cases
    identified for a class is valid for a subclass of
    that class.
   Additional test cases usually apply to a
    subclass.
                                                    3
Subclass test requirements
   Testing a class in an inheritance
    hierarchy is generally more
    straightforward when approached from
    the top down.
       In testing the top classes in the hierarchy,
        we can address the common interface and
        code and then specialize the test driver
        code for each subclass.

                                                  4
Subclass test requirements:
refinement possibilities
   Four general ways to define a new
    derived class that differ from its parent
    class:
       Add a new operation in the interface of the
        derived class and possibly a new method
        to implement each new operation.
       Change the specification or implementation
        of an operation from the superclass
            Change in the subclass the specification for an
             operation declared in the parent class.
            Override in the subclass a method in the parent
                                                         5
Subclass test requirements:
refinement possibilities (cont...)
   All the test cases that apply for the
    parent class should apply for the
    subclass.
   We need new additional test cases for
    the new operations.




                                            6
Subclass test requirements:
refinement possibilities (cont...)




                                     7
Subclass test requirements:
Hierarchical, incremental testing
(HIT)
   The incremental changes between class
    C and its derived class D can be used
    to guide the identification of what needs
    to be tested in D.
   Inherited test cases: test cases for a
    subclass that were identified for testing
    its base class.

                                          8
Subclass test requirements:
Hierarchical, incremental testing
(cont...)
   Use analysis to determine for a
    subclass
       What test cases need to be added
       What inherited test cases need to be run
       What inherited test cases do not need to
        be run



                                                   9
Organizing testing software
   Parallel architecture for class testing
    (PACT): We can develop a test driver for a
    subclass D by deriving its Tester class from
    the tester class of C (D’s superclass).




                                               10
Organizing testing software
(cont...)
   PACT reduces the effort needed to test a new
    subclass.
   If an operation is refined in a subclass, then
    the corresponding tester methods can be
    reused in the subclass and refined as
    necessary to reflect new preconditions,
    postcondition, and/or implementation.
   The root of the PACT hierarchy is the abstract
    class Tester.
                                               11
Organizing testing software
(cont...)
   Each subclass of Tester must provide
    implementations for the abstract operations and
    could override methods for any of the other
    operations.
   Each subclass has the following organization:
      Test case methods

      A method corresponding to each constructor to

       create an object under test.
      A method to create an object under test in some

       specified state.

                                                     12
Testing abstract classes
   Execution-based testing of a class
    requires that an instance of the class be
    constructed
   We can not create an instance of
    abstract class, so how to test an
    abstract class?



                                          13
Testing abstract classes:
approach 1
   A concrete subclass of the abstract
    class is defined solely for the purpose of
    testing:
       Disadvantage: the implementation of the
        abstract method cannot be propagated
        easily to abstract subclass without using
        multiple (repeated) instances.



                                                    14
Testing abstract classes: approach 1
(cont...)




                                  15
Testing abstract classes:
approach 2
   Test an abstract class as part of testing
    the first concrete descendent
       Advantage: no need develop extra classes
        for testing
       Disadvantage: increase the complexity in
        testing the concrete class.




                                              16
Testing abstract classes: approach 2
(cont...)




                                  17
Testing abstract classes:
approach 3
   Test an abstract class using guided inspection
    instead of execution-based testing
      Abstract class provides a little or no

       implementation for the abstract operations.
      Public interfaces for abstract classes stabilize

       quickly.
      Concrete operations can easily be tested by

       inspection
      But constructors and destructors are more

       complicated to be tested by inspection only.

                                                          18
Testing abstract classes:
recommendations
   Do execution-based testing.
   PACT offers advantages for testing
    families of classes.
   Use approach 2:
       Straightforward
       Requires relatively little additional coding
        effort for implementing testers.
       Easily perform regression testing.
                                                   19
Key points
   Inheritance provides a mechanism for interface and
    code reuse.
   Four ways to define a new derived class that differ
    from its parent class.
   Hierarchical, incremental testing (HIT): The
    incremental changes between class C and its derived
    class D can be used to guide the identification of
    what needs to be tested in D.
   Organizing testing software:
      Parallel architecture for class testing (PACT).

   Four approaches to test abstract classes.

                                                    20

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:2
posted:9/8/2012
language:Unknown
pages:20