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:
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. |