Therefore, in addition to testing the black-box behavior of the system, it may also be necessary to test the white-box behavior of the system. For white-box testing, we need to look inside the system and see how it does what it does. This process of internal inspection, often referred to as design assurance , looks at the architecture and implementation of the system to see whether or not it should perform correctly. Do use cases help us in white-box testing?
In a word, yes . We saw in Chapter 25 that the problem of orthogonality (the difference between the methods and representations we used to express the requirements imposed on the system and the methods and representations we used to implement the system) can be largely mitigated with use cases. With our method, for every use case, there is a use-case realization that represents how the system is designed to accomplish the use case. The use case itself lives in the problem or requirements domain and simply specifies necessary behavior. The use-case realization lives inside the solution domain and describes how the behavior is accomplished by the system (Figure 26-3).
Figure 26-3. Use case and its associated use-case realization
Further, as we learned in Chapter 25, the use-case realization is composed of both a static and a dynamic part. The static part can be reviewed and analyzed for its fitness to the intended purpose. The dynamic part can be analyzed by inspection or viewed with runtime emulators, debug code stubs, and a variety of other execution testing techniques.