Design – Build – Run: Applied Practices and Principles for Production-Ready Software Development

23.3. Using Stubs and Simulators

Stubs and simulators, in my opinion, are different entities. I tend to draw the following distinctions:

• A stub is simply an end-point. Stubs can contain some rudimentary logging to output the various parameters it was passed, and it can return a specific value to indicate success. Stubs are typically used when the real component isn't available and nothing specific in the consumer needs to be tested.

• A simulator is used when a component is either not available or specific "conditions" need to be tested. The simulator can implement logic based on parameters passed in or through configuration to return specific values or to throw specific exceptions. For instance, during testing, you might want to test your exception-handling routine. To do this thoroughly, you need to get the component you're calling to throw the various exceptions you expect. This can be quite difficult to arrange when using the real component. It might involve specific timing or other complicated environmental set-up. Using a simulator enables you to simulate the various conditions quickly and easily.

Figure 23-4 shows a holistic (cloud) view of the case study. The clouds represent the underlying processing, and the resulting outputs are noted. In this instance, processing output can be presented on the web page, in the database, or represented as diagnostic information as well as solicited e-mails.

Figure 23.4. Figure 23-4

The important thing with stubs and simulators is to ...