Testing Object Oriented Software Mauro Pezz` e Universit` a degli Studi di Milano Bicocca Dip. Informatica, Sistemistica e Comunicazione Via Bicocca degli Arcimboldi, 8 20126 Milano (Italy) pezze@disco.unimib.it Michal Young University of Oregon Dept. of Computer Science 1202, Deschutes Hall Eugene, OR 97403 (USA) michal@cs.uoregon.edu 1. Test and Analysis in the context of OO soft- ware Object oriented software requires reconsidering and adapting approaches to software test and analysis. Char- acteristics of object oriented software that impact test and analysis include state dependent behavior, encapsu- lation, inheritance, polymorphism and dynamic binding, abstract classes, exception handling, and concurrency. While test designers should be prepared to adopt new testing approaches for object-oriented software, they cannot ignore traditional technology and methodologies. An object oriented design approach mainly affects detailed design and code, but planning, requirements analysis, architectural de- sign, deployment and maintenance are largely independent of the use of a specific design approach and can be can and should be addressed with traditional methods and technol- ogy. The best approach to testing object oriented software de- pends on many factors: the application-under-test, the de- velopment approach, the organization of the development and quality assurance teams, the criticality of the applica- tion, the development environment and the implementation language(s), the use of design and language features, project timing and resource constraints. Nonetheless, we can out- line a general approach that works in stages from indepen- dent consideration of classes and their features to consid- eration of their interactions. A coherent strategy would in- clue three main phases: intra-class, inter-class, and system and acceptance testing. Intra-class testing deals with classes in isolation and in- cludes testing of abstract classes, selection of test cases from the ancestors’ test suite, and testing state-dependent behavior of the class under test. Inter-class testing applies to clusters of classes to be tested incrementally, considering class interactions, polymorphic calls, and exception han- dling. System and Acceptance testing considers the software as a whole independently from its internal structure and re- lies on traditional system and acceptance testing techniques. 2. State-dependent behavior and encapsula- tion Since the state of an object is implicitly part of the in- put and output of methods, we need a way to systemat- ically explore object states and transitions. This can be done using a state machine model, which can be derived from module specifications. State machines can be traversed with different criteria for deriving state based test cases: history-insensitive criteria produce relatively small sets of test cases, and are thus well suited for testing large applica- tions with stringent cost constraints; history-sensitive crite- ria produce more thorough test suites that contain more test cases, and thus apply well to small applications with strin- gent quality requirements. When moving from intra- to inter-class testing, we must combine different state machines. Approaches that consider all combinations of possible interactions are usually im- practical. Practical criteria can be derived from combina- tions of random selection of interactions with explicit test- ing of significant interaction scenarios that have been iden- tified in design and analysis, e.g., in the form of UML inter- action diagrams. Structural testing criteria must also take into account ob- ject state. Since the state of a class is comprised of the set of values of the instance variables of the class, the num- ber of states can be enormous. We can radically reduce the size of test sets while remaining sensitive enough to catch many common oversights by modeling the points at which the variables change value. This is the same intuition be- hind data flow testing, although it requires some extension to cover sequences in which one method defines (sets) the variable, and another uses the variable. Intra- and inter-class testing require suitable scaffolding to exercise the classes under test (drivers and stubs) and to inspect the test results (oracles). Constructing stubs and Proceedings of the 26th International Conference on Software Engineering (ICSE’04) 0270-5257/04 $20.00 © 2004 IEEE