Object-Oriented Integration Testing


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,

DOI: 10.1145/182987.182989

Extracted Key Phrases

3 Figures and Tables


Citations per Year

134 Citations

Semantic Scholar estimates that this publication has 134 citations based on the available data.

See our FAQ for additional information.

Cite this paper

@article{Jorgensen1994ObjectOrientedIT, title={Object-Oriented Integration Testing}, author={Paul C. Jorgensen and Carl Erickson}, journal={Commun. ACM}, year={1994}, volume={37}, pages={30-38} }