Testing Object-Oriented Systems
More than ever, mission-critical and business-critical issues depend on object-oriented (OO) software. Testing techniques tailored to the unique challenges of OO technology are necessary to achieve high reliability and quality. This book is an authoritative guide to designing and automating test suites for OO applications. This comprensive book explains why testing must be model-based. It provides in-depth coverage of techniques to develop testable models from state machines, combinational logic and the Unified Modeling Language (UML).
It introduces the test design and presents 37 patterns that explain a number of "how-to" issues: how to design responsibility-based test suites, how to tailor integration and regression testing for OO code, how to test reusable components and frameworks, and how to develop highly effective test suites from use cases.
Review By: Lee Copeland
09/13/2002Weighing in at four and one-half pounds, Robert Binder's 1100 page book Testing Object Oriented Systems is the biggest book ever written on this subject. It is also the best!
Binder's philosophy is to test models of object oriented systems before testing their implementation. He writes, "Testing can be viewed as a search problem. We are looking for those few input and state combinations that will reach, trigger, and propagate bugs out of trillions and trillions which will not. Brute force is impotent at this scale. Testing by poking around is a waste of time that leads to unwarranted confidence"(p. 111). To support this philosophy he presents testing approaches for use cases, class diagrams, sequence diagrams, and state-transition diagrams. Discussions are supplemented with detailed checklists that can be used by both developers and testers to evaluate these models.
Binder's approach covers the total spectrum of system development from class through cluster, component, subsystem, and system testing. The author takes the seminal idea of design patterns and extends it into the object oriented testing arena by describing thirty-seven test patterns. Examples include:
Combinational Function-Design a test suite according to combinations of state and/or input message values.
Polymorphic Message Test-Develop tests for a client of a polymorphic server that exercise all client bindings to the server.
Modal Class-Develop a class-level test suite for a class that has fixed constraints on message sequence.
Polymorphic Server-Design a test suite that verifies Liskov Substitution Principle compliance for a polymorphic server hierarchy.
Abstract Class-Develop a test implementation of and a test suite for an abstract class interface.
New Framework-Develop a test implementation of and a test suite for a framework that has few (if any) instantiations.
Class Associations-Design a test suite to verify the implementation of required associations among classes.
Layers-Use an incremental approach to verify stability in system implemented with a layered architecture.
Covered in CRUD-Verifies that all basic operations (create, read, update, delete) are exercised.
A valuable part of the test patterns he describes is the fault model-an assumption of where faults are likely to be found and thus an explanation for why a particular testing strategy is likely to be effective. For example, in describing the problems associated with testing inheritance structures Binder writes, "The object oriented programming paradigm presents a unique blend of powerful constructs, bug hazards, and testing problems.... Each lower level in an inheritance hierarchy creates a new context for inherited features; correct behavior at an upper level in no way guarantees correct behavior at a lower level...Polymorphism and dynamic binding dramatically increase the number of execution paths...Static analysis of source code to identify paths (a bedrock technique of procedural testing) is of little use" (pp. 67-68).
Aside from a few minor typos which are typical of the first printing of a book of this complexity, the only criticism I can imagine people making is the book's sheer size. In the movie "Amadeus" the emperor Joseph II criticizes Mozart's new composition saying, "My dear young man, don't take it too hard. Your work is ingenious. It's quality work. And there are simply too many notes, that's all. Cut a few and it will be perfect." The absurdity of his comment is evident to all. To those who would suggest to Binder that he also has too many notes, consider Mozart's reply, "Which few did you have in mind, Majesty?"