What Is Different about Testing Object-Oriented Software?

Object-oriented programming features in programming languages obviously impact some aspects of testing. Features such as class inheritance and interfaces support polymorphism in which code manipulates objects without their exact class being known. Testers must ensure the code works no matter what the exact class of such objects might be. Language features that support and enforce data hiding can complicate testing because operations must sometimes be added to a class interface just to support testing. On the other hand, the availability of these features can contribute to better and reusable testing software.

Not only do changes in programming languages affect testing, but so do changes in the development process and changes in the focus of analysis and design. Many object-oriented software-testing activities have counterparts in traditional processes. We still have a use for unit testing although the meaning of unit has changed. We still do integration testing to make sure various subsystems can work correctly in concert. We still need system testing to verify that software meets requirements. We still do regression testing to make sure the latest round of changes to the software hasn't adversely affected what it could do before.

The differences between "old" and "new" ways of developing and testing software are much deeper than a focus on objects instead of on functions that transform inputs to outputs. The most significant difference is in the way object-oriented software is designed as a set of objects that essentially model a problem and then collaborate to effect a solution. Underlying this approach is the concept that while a solution to a problem might need to change over time, the structure and components of the problem itself do not change as much or as frequently. Consequently, a program whose design is structured from the problem (and not on an immediately required solution) will be more adaptable to changes later. A programmer familiar with the problem and its components can recognize them in the software, thereby making the program more maintainable. Furthermore, because components are derived from the problem, they can often be reused in the development of other programs to solve similar or related problems, thereby improving the reusability of software components.

A big benefit of this approach to design is that analysis models map straightforwardly to design models that, in turn, map to code. Thus, we can start testing during analysis and refine the tests done in analysis to tests for design. Tests for design, in turn, can be refined to tests of implementation. This means that a testing process can be interwoven with the development process. We see three significant advantages to testing analysis and design models:

1. Test cases can be identified earlier in the process, even as requirements are being determined. Early testing helps analysts and designers to better understand and express requirements and to ensure that specified requirements are "testable."

2. Bugs can be detected early in the development process, saving time, money, and effort. It is widely acknowledged that the sooner problems are detected, the easier and cheaper they are to fix.

3. Test cases can be reviewed for correctness early in a project. The correctness of test cases in particular, system test cases is always an issue. If test cases are identified early and applied to models early in a project, then any misunderstandings of requirements on the part of the testers can be corrected early. In other words, model testing helps to ensure that testers and developers have a consistent understanding of system requirements.

Although testing models is very beneficial, it is important to not let testing them become the sole focus of testing efforts. Code testing is still an important part of the process.

Another difference between traditional projects and projects using object-oriented technologies concerns objectives for software. Consider, for example, that an important new goal in many companies is to produce reusable software, extensible designs, or even object-oriented frameworks that represent reusable designs. Testing can (and should) be done to uncover failures in meeting these objectives. Traditional testing approaches and techniques do not address such objectives.