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,
Unfortunately, ACM prohibits us from displaying non-influential references for this paper.
To see the full reference list, please visit http://dl.acm.org/citation.cfm?id=182989.