Open Issues in Testing Object-Oriented Software

vdf Hochschulverlag AG an der ETH Zürich, 1994
Article de conférence

Résumé

While the use of object-oriented development methods has increased the quality of software by leading to better, modular architectures, it does not provide correctness by itself. Thus, testing software remains an important task even in the presence of object-orientedness. The traditional testing methods decompose software into procedures. However, the dimensions of object-oriented programming are such that this decomposition is ill-fitted for testing object-oriented programs. We address the problems of testing in the three dimensions of object-oriented software: classes, hierarchies, subsystems. The class forms a well-defined basic test unit; however its testing is impeded by encapsulation and inheritance issues. The class hierarchy concept introduces problems of undecidability due to polymorphism. Subsystems are the building blocks in integration testing. We also study the use of traditional methods and the modifications that are needed to apply them to object-oriented software, e.g. complexity metrics.

Official source

https://infoscience.epfl.ch/record/54516?ln=fr

À propos de ce résultat

Cette page est générée automatiquement et peut contenir des informations qui ne sont pas correctes, complètes, à jour ou pertinentes par rapport à votre recherche. Il en va de même pour toutes les autres pages de ce site. Veillez à vérifier les informations auprès des sources officielles de l'EPFL.

Concepts associés

Chargement

Publications associées

Chargement

The Problematics of Testing Object-Oriented Software

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

Chargement

Ada 9X for Object-Oriented Programming

Ada 9X -the revised definition of the Ada programming language- provides support for object-oriented programming. This course examines the new, object-oriented features of the language, their use, and how they fit into Ada's strong type system and genericity mechanisms. Basic object-oriented mechanisms are covered, such as: extension, inheritance, and polymorphism. We then show how to integrate these mechanisms into good programming practices; topics will include incremental programming, heterogeneous data structures, mixin inheritance, and design for reuse. We will also compare standard object-oriented idioms as implemented in Ada vs. other object-oriented languages (e.g. C++, Eiffel).

1994

Chargement

In a growing number of applications, different complementary views of real-world objects are needed. This is particularly true in spatial modelling - where the designer can propose different geometries for a given spatial object - or, in temporal modelling -where different life cycles can be defined on an object depending on the adopted point of view. A solution to provide multiple representations on objects is to offer a model supporting multiple instantiation, i.e. allowing real world entities to be instantiated in several classes. At the same time, object-oriented languages and object-oriented modelling have become common in computer science (C++ and Java for the former and UML (Rum.,97) for the latter). Hence, oriented-object properties as inheritance, polymorphism and dynamic binding are commonly used and their expressiveness quite naturally exploited. However, classical object-oriented models and languages onlyallow an implicit form of multiple instantiation among an inheritance hierarchy, i.e. an instance of a class is also a member of all its super-classes. In this paper we propose a solution to integrate classical object oriented mechanisms into models handling multiple instantiation and illustrate it on the conceptual model MADS. To achieve this, the dynamic binding mechanism was revisited, through the concept of scope of an instance (awareness of other instances), in order to manage the ambiguities induced by multiple instantiation. Last, providing an operational solution, a set of operators to modify the point of view of an object (determining which of its class instances is considered) and its scope is defined.

2000

Chargement