Introduction to Testing Object-Oriented Software
- Oct 19, 2001
Testing software well has always been challenging, but the process is fairly well understood. Some combination of unit testing, integration testing, system testing, regression testing, and acceptance testing will help to deliver usable systems.
We wanted to write this book because most people seem to believe that testing object-oriented software is not much different from testing procedural software. While many of the general approaches and techniques for testing are the same or can be adapted from traditional testing approaches and techniques, our experience and our research has demonstrated that some things are different and present new challenges. At the same time, well-designed object-oriented software developed as part of an incremental process provides opportunities for improvements over traditional testing processes.
Object-oriented programming language features of inheritance and polymorphism present new technical challenges to testers. We describe solutions for many of these challenges. In this book, we describe processes and techniques for testing object-oriented software effectively during all phases of a development effort. Our approach to testing software is quite comprehensive and one that we believe software development organizations should undertake. At the same time, we realize that resources available for testing are limited and that there are many effective ways to develop software, so we think it is reasonable to pick and choose among the techniques we present in this book.
The adoption of object-oriented technologies brings changes not only in the programming languages we use but in most aspects of software development. We use incremental development processes, refocus and use new notations for analysis and design, and utilize new programming language features. The changes promise to make software more maintainable, reusable, flexible, and so on. We have written this book because changes in the way we develop software produces changes in the way we test software, from both managerial and technical perspectives. The following changes provide opportunities for improving the testing process:
We have an opportunity to change attitudes toward testing. In many environments, managers and developers view testing as a necessary evil. Testing that needs to be done by the developers themselves interrupts code production. Reviews, code inspections, and writing unit test drivers take time and money. Testing processes imposed on the developers for the most part just get in the way of coding. However, if we can make everyone appreciate that testing contributes to developing the right software from the start, and that it can actually be used to measure progress and keep development on track, then we can build even better software.
We have an opportunity to change where testing fits into a development process. Almost everyone recognizes that the sooner problems are found, the cheaper they are to fix. Unit testing and integration testing uncover problems, but don't usually start until coding has started. System testing is typically done near the end of a development effort or perhaps at certain planned milestones. System testing is treated as a way to see how well the developers did in meeting requirements. Of course, this is a wrong approach. Decisions about how much testing is adequate, when it should be performed, and who should do it should be made only in the context of a well-considered testing strategy that works with the project's software development process. We will show how testing activities can begin early. We will show how testing and development activities can be intertwined and how each can contribute to a successful outcome of the other.
We have an opportunity to use new technology to do the testing. Just as object-oriented technologies have benefits for production software, they also can realize benefits in test software. We will show how you can test object-oriented analysis and design models, and how you can use object-oriented programming techniques to develop unit test drivers and reduce the coding necessary to test software components.
Who Should Read This Book?
We have written this book for
Programmers who already work in testing software, but want to know more about testing object-oriented software.
Managers who are responsible for software development and who would like to know how and where testing fits into a plan.
Developers who are responsible for testing the software they produce and who should take testing issues into consideration during the analysis, design, and coding activities.
With such a wide audience, we struggled with the level of detail we needed to include about object-oriented development and testingthe basic concepts associated with software testing, object-oriented programming, and the Unified Modeling Language (UML) to express analysis and design results. We decided to provide brief overviews of these topic areaswhat we consider the minimum a reader needs to know to make sense of what we have to say. When we need to resort to code, we use C++ and Java. The approaches and techniques we present apply to all object-oriented programs, not just to those written in C++ and Java.
We have assumed the following software-development scenario, which we consider to be ideal:
The process must be incremental, with iterations that occur within each increment.
The models expressed in UML must be available.
The software design must be in accordance with good design principles with respect to the use of inheritance, data hiding, abstraction, low coupling, and high cohesion.
However, we realize that most organizations have their own processes and notations. Consequently, our focus is primarily on principles and techniques.