Testing levels for object-oriented software

Abstract

One of the characteristics of object-oriented software is the complex dependency that may exist between classes due to inheritance, association and aggregation relationships. Hence, where to start testing and how to define an integration strategy are issues that require further investigation. This paper presents an approach to define a test order by exploiting a model produced during design stages (e.g., using OMT, UML), namely the class diagram. Our goal is to minimize the number of stubs to be constructed in order to decrease the cost of testing. This is done by testing a class after the classes it depends on. The novelty of the test order lies in the fact that it takes account of: (i) dynamic (polymorphism) dependencies; (ii) abstract classes that cannot be instantiated, making some testing levels infeasible. The test order is represented by a graph showing which testing levels must be done in sequence and which ones may be done independently. It also provides information about the classes involved in each level and how they are involved (e.g., instantiation or not). The approach is implemented in a tool called TOONS (Testing level generator for Object-OrieNted Software). It is applied to an industrial case study from the avionics domain.

A Study of Test Coverage Adequacy In the Presence of Stubs.

“…The difficulty of testing abstract classes is well documented [3,11,15,18,25]. The main problem is that, for most languages that support object technology, abstract classes cannot be instantiated.…”

“…The main problem is that, for most languages that support object technology, abstract classes cannot be instantiated. Reference [15] describes an approach for computing an ordering of classes for testing in the presence of abstract classes; however, for the most part abstract classes are ignored in the ordering methodology literature. strategies involve using a derived class, either an existing derived class or a stub, to enable testing of the abstract class [3,18,25].…”

“…If class A uses class B, then A is said to be a client of B and B is a supplier of class A. One of the challenges in such testing is to order the classes for testing in the presence of class interactions or dependencies [5,14,15,17]. To order the classes, an object relation diagram, ORD, is constructed where the nodes in the ORD are classes and the edges express dependencies between the classes.…”

“…For an ORD with cycles, previous research has proposed the removal of edges in the ORD until cycles are broken and, to test a client class that uses an untested supplier class, stubs should be constructed to approximate the behavior of the untested supplier class [14,15,17,24]. For example, the ORD on the right side of Figure 1 illustrates the removal of the edge from C to A, with a stub approximating the behavior of class A.…”

Selecting an Efficient OO Integration Testing Strategy: An Experimental Comparison of Actual Strategies

“…In the paper, the performance of a strategy is thus related to the number of generated stubs and the number of integration steps. Among the many existing proposals [4,6,9,10,11,13] that deal with this problem, we concentrate on those of David C. Kung and al. [10] and Kuo Chung Tai & Fonda J. Daniels [4] since they both detail effective and feasible algorithms.…”