Object-oriented integration testing
Paul C. Jorgensen, Carl T. Erickson · Communications of the ACM · 1994
OrientedIntegKItCO~ 0 bject-oriented software development raises important testing issues.Many of these stem from attempts to directly apply theoretical constructs and techniques of traditional software develop ment and testing to object-oriented software.We examine this traditional heritage here, with special emphasis on assumptions and practices that need to be modified or replaced.We identify five levels of objectoriented testing; four of these map nicely into the commonly accepted unit, integration, and system levels of traditional software testing.(Placement of the remaining level is primarily a management consideration.)We also identify two new testing constructs and a directed graph notation that helps formalize object-oriented integration testing.These are illustrated with an object-oriented formulation of an automated teller machine (ATM) system.The source code (ObjectiveC) for this system is available from the authors.We begin with an important distinction: structure vs. behavior.Most of the popular notations used in software development (E/R models, data flow diagrams, structure charts, PDLs, and so on) portray software structure: the components, relationships among these, the interfaces,