Object-Oriented Testing

< Free Open Study >

Object-Oriented Testing In Chapter 4, we discussed how most prototyping and object-oriented (OO) projects proceed according to a life cycle that is quite different from the waterfall model. In Chapter 22, we discussed OO modeling techniques, which are distinct from more traditional structured analysis/structured design techniques. It only makes sense that with these differences in place, testing would assume different characteristics as well. In traditional terms, the smallest testable item is the unit, or module, which can be tested with white-box tests. In OO, this functional item is not separated from its class, where it is encapsulated with its methods. This means unit testing is basically replaced with class testing. However, we don't stray too far from our roots in that each object class method (operation or service) could be considered a "small unit" and tested alone, before test sequences, with white- and black-box tests. Individual object classes may continue to employ black-box concepts as well. Object classes need to be exercised in all possible states, meaning that all events that cause a state change in the object should be simulated. In traditional terms, units are put together into subsystems and are subjected to integration tests. With OO, testing a structure chart from the top down and bottom up doesn't apply because we are never sure "who's in control" or what class will be called upon next by the user. Integration tests are replaced with thread-based testing, which tests the set of classes required to respond to one input or system event, or use-based testing, which describes one mode of use of the system based on use case scenarios. Object interaction testing follows "method message" paths to trace a sequence of object interactions that ends only when the last object has been invoked (it doesn't send a message to or call upon the services of any other object.) System, alpha, beta, usability, and user acceptance testing change very little because the OO system will undergo user-based tests just as traditionally developed systems. This means that V&V are essentially the same. Showing that a system conforms to requirements specifications and is of an acceptable quality level is always the goal of V&V.

< Free Open Study >