A unit test verifies a particular outcome from a single activity. System tests, on the other hand, verify the proper execution of a use case that may involve multiple system interactions by multiple actors. Figure 15.9 shows all the activities in the Order Merchandise use case. Figure 15.9. Activity Diagram for the Use Case Order MerchandiseSystem tests share many of the same characteristics of unit tests: Both begin by establishing the state of the system based on preconditions, both have execution traces started by an initial signal, and both terminate with results that can be verified against postconditions. The principal distinction is when the execution trace ends. For a unit test, the trace ends when there are no more signals to process, but for a larger use case, the conclusion of one activity merely means that there are more activities to be done. For example, when the customer checks out the order (one activity), that is followed by another activity by the credit card company either to accept or to decline the charge. A system test should therefore chain together the activities that make up the use case. It does this by recognizing the completion of one activity and then initiating the subsequent activities. Recognizing completion of an activity means there are no more signals to process. This could mean that the activity has produced outbound signals or that the trace has transitioned into a state that generates no signals. Once activity completion is recognized, the test must verify the correct execution of the activity and, depending on the outcome of the test, initiate the subsequent activity. Generally, it should not be necessary to do any work to set up the state of the system for the next activity, as the postcondition of one activity should match up to the precondition for the subsequent activity.[2] To build distinct scenarios for system tests, identify different combinations of state-of-the-system conditions and initial signal parameters.
Additionally, a use case's activity diagram may show several different subsequent activities for a given activity. For example, after each Add Item, the customer can either add another item or check out. Different scenarios can yield the one-item order, the two-item order with different products, the two-item order with the same product, and so forth. System tests are executed much like unit tests, except the test script has code to recognize the completion of one activity and to initiate the next activity automatically. For example, when the credit card charge is created, we send in a signal that either approves or declines the charge. The result of a system test can be documented on a collaboration or sequence diagram such as the one in Figure 15.10. A model verifier tool should generate these diagrams. Though they provide a good visual overview of an execution trace, they are incredibly painful to draw by hand. Figure 15.10. Sequence Diagram for Multiple-Item Ordering Scenario |