Within object-oriented approaches, testing has almost been ignored in favor of analysis, design, and coding. However, object-orientedness does not solve the problem of testing by itself and may even induce new problems. Most work in testing has been done with "procedure-oriented" software in mind. Traditional methods, despite their efficiency, cannot be applied without adaptation to object-oriented systems. In an object-oriented system, the basic unit of testing is a class instead of a subprogram; testing should hence focus on classes and objects. Moreover, it is not possible to test the operations of a class in isolation, as they interact with each other by modifying the state of the object they are applied to. Sometimes testing object-oriented software can benefit from object-oriented technology, for instance, by capitalizing on the fact that a superclass has already been tested, and by decreasing the effort to test derived classes, which reduces the cost of testing in comparison with a flat class structure. The object-oriented paradigm can also be a hindrance to testing, due to the nature of some aspects of its very nature: encapsulation, inheritance and polymorphism. In the presence of encapsulation, the only way to observe the state of an object is through its operations; there is therefore a fundamental problem of observability. Inheritance opens the issue of re-testing. Should operations inherited from ancestor classes be re-tested in the context of the descendant class? A case analysis will show that there is no definite answer. Polymorphic calls are difficult to test. A test suite must ensure that all possible cases of bindings are covered. Moreover, when extending a software by a new derived class (programming by extension), calls with possible bindings to operations of this new derived class must be re-tested.
1994
