Intra-Class Testing of Abstract Class Features

Abstract

One of the characteristics of the increasingly widespread use of object-oriented libraries and the resulting intensive use of inheritance is the proliferation of dependencies on abstract classes. Such classes defer the implementation of some features, and are typically used as a specification or design tool. However, since their features are not fully implemented, abstract classes cannot be instantiated, and thus pose challenges for execution-based testing strategies. This paper presents a structured approach that supports the testing of features in abstract classes. Core to the approach is a series of static analysis steps that build a comprehensive view of the inter-class dependencies in the system under test. We then leveraged this information to define a test order for the methods in an abstract class that minimizes the number of stubs required during testing, and clearly identifies the required functionality of these stubs.Our approach is based on a comprehensive taxonomy of object-oriented classes that provides a framework for our analysis. First we describe the algorithms to calculate the inter-class dependencies and the test-order that minimizes stub creation. Then we give an overview of our tool, AbstractTestJ that implements our approach by generating a test order for the methods in an abstract Java class. Finally, we harness this tool to provide an analysis of 12 substantial Java applications that demonstrates both the feasibility of our approach and the importance of this technique. IntroductionThe widespread use of object-oriented (OO) libraries, and more recently plug-ins for integrated development environments (IDEs), has led to an emphasis being placed on validating the correct behavior of these components. These components extensively use the properties of the OO paradigm, i.e., abstract data types, inheritance and dynamic binding of method calls. One of the properties of inheritance that increases its flexibility is the ability to defer the implementation of members in one class, an abstract class, to one or more of its concrete derived classes. Many of the previously mentioned components implement design patterns that use abstract classes as a key part of their implementation.A plethora of testing techniques have been developed during the last two decades to test OO software. These OO testing techniques cover all the phases of the development cycle, from unit testing through system testing. Most of the testing techniques focus on aspects of the specification, implementation, or a combination of both. One area of testing OO software that has not received much attention is testing of abstract classes. This lack of concentration partially stems from the inability to instantiate objects of abstract classes, thereby preventing them from being able to be executed at runtime. However, there are benefits to be gained from testing the functionality of abstract classes. One such benefit is the reuse of test cases from the test history of the abstract class to validate any of its concrete derived...

A testing strategy for abstract classes

“…The work presented in this paper is an extension of the previous work by Clarke et al 5. In this previous work an automated approach was presented to test the methods of an abstract class by testing the methods in the concrete descendant classes, or a new class created solely for the purposes of testing.…”

“…When conducting the research presented in the paper by Clarke et al 5, it became apparent that there was relatively little existing research on the role or importance of abstract classes in testing. In particular, given the difficulty of testing abstract classes, it is reasonable to ask whether the effort is worthwhile.…”

“…Originally a different suite of applications was selected based on a subjective evaluation of their merit. This initial suite of applications was similar to the one used by Clarke et al 5. However, a recent empirical study by Melton and Tempero used a large corpus of Java applications to study dependency and inheritance relationships between classes 6, 7.…”

“…This paper presents a strategy for testing abstract classes which is an extension of the work presented by Clarke et al 5. The underlying idea of the strategy is that since objects of an abstract class cannot be instantiated, the methods of the abstract class must be tested in a concrete subclass of the abstract class.…”

“…The major contributions of this paper include two empirical studies that were performed to further validate the strategy used to test abstract classes presented by Clarke et al 5. The applications used in the studies were the 16 large open‐source Java applications from a corpus used by Melton and Tempero in their study on dependency and inheritance relationships between classes 6, 7.…”