Testing Object-Oriented Systems:... | Buy

Summary

More than ever, mission-critical and business-critical applications depend on object-oriented (OO) software. Testing techniques tailored to the unique challenges of OO technology are necessary to achieve high reliability and quality. Testing Object-Oriented Systems: Models, Patterns, and Tools is an authoritative guide to designing and automating test suites for OO applications. This comprehensive book explains why testing must be model-based and 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 pattern and presents 37 patterns that explain 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. Effective testing must be automated and must leverage object technology. The author describes how to design and code specification-based assertions to offset testability losses due to inheritance and polymorphism. Fifteen micro-patterns present oracle strategies--practical solutions for one of the hardest problems in test design. Seventeen design patterns explain how to automate your test suites with a coherent OO test harness framework. The author provides thorough coverage of testing issues such as: bull; bull;The bug hazards of OO programming and differences from testing procedural code bull;How to design responsibility-based tests for classes, clusters, and subsystems using class invariants, interface data flow models, hierarchic state machines, class associations, and scenario analysis bull;How to support reuse by effective testing of abstract classes, generic classes, components, and frameworks bull;How to choose an integration strategy that supports iterative and incremental development bull;How to achieve comprehensive system testing with testable use cases bull;How to choose a regression test approach bull;How to develop expected test results and evaluate the post-test state of an object bull;How to automate testing with assertions, OO test drivers, stubs, and test frameworks Real-world experience, world-class best practices, and the latest research in object-oriented testing are included. Practical examples illustrate test design and test automation for Ada 95, C++, Eiffel, Java, Objective-C, and Smalltalk. The UML is used throughout, but the test design patterns apply to systems developed with any OO language or methodology. 0201809389B04062001

Author Biography

Robert V. Binder is president and founder of RBSC Corporation.

Part I Preliminaries

(108)

A Small Challenge

(8)

How to Use This Book

(30)

Testing: A Brief Introduction

(22)

With the Necessary Changes: Testing and Object-oriented Software

(46)

Part II Models

109

(206)

Test Models

111

(10)

Combinational Models

121

(54)

State Machines

175

(94)

A Tester's Guide to the UML

269

(46)

Part III Patterns

315

(484)

Results-oriented Test Strategy

317

(30)

Classes

347

(178)

Reusable Components

525

(38)

Subsystems

563

(64)

Integration

627

(88)

Application Systems

715

(40)

Regression Testing

755

(44)

Part IV Tools

799

(266)

Test Automation

801

(6)

Assertions

807

(110)

Oracles

917

(40)

Test Harness Design

957

(108)

Appendix

1065

(8)

Glossary

1073

(46)

References

1119

(24)

Index

1143

Supplemental Materials

What is included with this book?

The New copy of this book will include any supplemental materials advertised. Please check the title of the book to determine if it should include any access cards, study guides, lab manuals, CDs, etc.

The Used, Rental and eBook copies of this book are not guaranteed to include any supplemental materials. Typically, only the book itself is included. This is true even if the title states it includes any access cards, study guides, lab manuals, CDs, etc.

Excerpts

What Is This Book About? Testing Object-Oriented Systemsis a guide to designing test suites and test auto- mation for object-oriented software. It shows how to design test cases for any object-oriented programming language and object-oriented analysis/design (OOA/D) methodology. Classes, class clusters, frameworks, subsystems, and application systems are all considered. Practical and comprehensive guidance is provided for many test design questions, including the following: How to design responsibility-based tests for classes and small clusters using behavior models, state-space coverage, and interface dataflow analysis. How to use coverage analysis to assess test completeness. How to design responsibility-based tests for large clusters and subsystems using dependency analysis and hierarchic state models. How to design responsibility-based tests for application systems using OOA/D models. How to automate test execution with object-oriented test drivers, stubs, test frameworks, and built-in test. This book is about systems engineering and software engineering as much as it is about testing object-oriented software. Models are necessary for test design--this book shows you how to develop testable models focused on preventing and removing bugs. Patterns are used throughout to express best practices for designing test suites. Tools implement test designs--this book shows you how to design effective test automation frameworks. Is This Book for You? This book is intended for anyone who wants to improve the dependability of object-oriented systems. The approaches presented range from basic to advanced. I''ve tried to make this book like a well-designed kitchen. If all you want is a sandwich and a cold drink, the high-output range, large work surfaces, and complete inventory of ingredients won''t get in your way. But the capacity is there for efficient preparation of a seven-course dinner for 20 guests, when you need it. I assume you have at least a working understanding of object-oriented programming and object-oriented analysis/design. If you''re like most OO developers, you''ve probably specialized in one language (most likely C++ or Java) and you may have produced or used an object model. I don''t assume that you know much about testing. You will need some background in computer science and software engineering to appreciate the advanced material in this book, but you can apply test design patterns without specialized theoretical training. You''ll find this book useful if you must answer any of the following questions. What are the differences between testing procedural and object-oriented software? I''ve just written a new subclass and it seems to be working. Do I need to retest any of the inherited superclass features? What kind of testing is needed to be sure that a class behaves correctly for all possible message sequences? What is a good integration test strategy for rapid incremental development? How can models represented in the UML be used to design tests? What can I do to make it easier to test my classes and applications? How can I use testing to achieve greater reuse? How should I design test drivers and stubs? How can I make my test cases reusable? How can I design a good system test plan for an OO application? How much testing is enough? The material here is not limited to any particular OO programming language, OOA/D methodology, kind of application, or target environment. However, I use the Unified Modeling Language (UML) throughout. Code examples are given in Ada 95, C++, Java, Eiffel, Objective-C, and Smalltalk. A Point of View My seven-year-old son David asked, "Dad, why is your book so big?" I''d just told David that I''d have to leave his baseball game early to get back to work on my book. I wanted to explain my choice, so I tried to be clear and truthful in answering. This is what I told David at the kitchen table on that bright summer afternoon: Testing is complicated and I''m an engineer. Making sure that things work right is very important for engineers. What do you think would happen if our architect - didn''t make our house strong enough because he was lazy? It would fall down and we could get hurt. Suppose the engineers at GM did only a few pages'' worth of testing on the software for the brakes in our car. They might not work when we need them and we''d crash. So when engineers build something or answer a question about how to build things, we have to be sure we''re right. We have to be sure nothing is left out. It takes a lot of work. As I was speaking, I realized this was the point of view I''d been struggling to articulate. It explains why I wrote this book and the way I look at the problem of testing object-oriented software. Testing is an integral part of software engineering. Object-oriented technology does not diminish the role of testing. It does alter some important technical details, compared with other programing paradigms. So, this is a large book about how testing, viewed as software engineering, should be applied to object-oriented systems development. It is large because testing and object-oriented development are both large subjects, with a large intersection. By the way--David hit two home runs later that afternoon while I was torturing the truth out of some obscure notions. Acknowledgments No one who helped me with this book is responsible for its failings.1Dave Bulman, Jim Hanlon, Pat Loy, Meilir Page-Jones, and Mark Wallace reviewed the first technical report about the FREE methodology Binder 94. 1. John Le Carre crafted this concise statement about assistance he received on The Tailor of Panama.I can''t improve on it. In 1993, Diane Crawford, editor of Communications of the ACM,accepted my proposal for a special issue on object-oriented testing, which was published in September 1994. The contributors helped to shape my views on the relationship between the development process and testing. Bill Sasso (then with Andersen Consulting and now answering a higher calling) sponsored a presentation where questions were asked that led to development of the Mode Machine Test pattern (see Chapter 12). Bob Ashenhurst of the University of Chicago, James Weber, and the rest of the Regis Study Group raised more fundamental questions: What is a state? Why should we care about pictures? The following year, Marie Lenzie, as editor of Object Magazine,accepted my proposal for a bimonthly testing column. Since 1995, writing this column has forced me to transform often hazy notions into focused, pragmatic guidance six times each year. Lee White of CASE Western Reserve University and Martin Woodward of the University of Liverpool, editors of the journal Software Testing, Verification, and Reliability,encouraged my work in developing a comprehensive survey, patiently waited, and then allocated an entire issue to its publication. Writing the survey helped to sort which questions were important, why they were asked, and what the best available thinking did and did not answer. My publications, conference tutorials, and professional development seminars on object-oriented testing served as a conceptual repository and proving ground. Many of these materials, with the necessary changes, have been reused here. The cooperation of RBSC Corporation, SIGS Publications, the ACM, the IEEE, and Wiley (U.K.) is appreciated in this regard (see preceding Sources and Credits for details). The real-world problems and questions posed by my consulting clients and thousands of seminar participants have been humbling and constant spurs to refinement. The patient support of Carter Shanklin and his predecessor