15.1 Finding ngle Use Case

15.1 Finding Unit Tests for a Single Use Case

Rather than trying to take on a whole use case, we can deal with it piece by piece, one activity at a time. Each activity is defined in terms of a set of preconditions, a single initiating signal, and a set of postconditions.^[1]

^[1] Unit tests apply to single-system interaction use cases, while system tests apply to activities grouped into larger use cases. We can use activity diagrams to show interactions between use cases at any level.

There may be several possible paths through each use case, such as Add Item to Order, because a use case is a specification of a set of possible behaviors. Each path is determined by combinations of system state and values for signal parameters, and each potential path through the use case is a scenario.

Definition: A scenario is the planned execution of a use case with ranges of values for signal parameters, initial states for state machine instances, and ranges of values for attributes of objects, so that there is only path through the model.

A scenario is the basis for each test case we want to execute, and each actual execution of a scenario is a test case.

To determine each test case, we must establish the system state and signal parameter values for the objects that distinguish the different scenarios.

To determine the objects that potentially participate in a scenario, use the collaboration diagram and the statechart diagrams to trace through the scenario informally and determine what state machines need to be considered and how many different instances of each are required.

In Add Item to Order, depicted in Figure 15.1, we have an arbitrary unspecified instance of an Order, a product with a quantity on hand, and depending on the scenario some number of selections. Herein lies a problem: There are several scenarios for a use case, and we generally determine which scenarios actually exist as we trace through what we believe to be a single scenario.

Figure 15.1. Use Case Add Item to Order

Happily, the preconditions help narrow the choices. For example, Add Item to Order has a precondition that the quantity on hand is greater than zero and less than stock on hand. Were that precondition missing or more loosely defined, there could be several scenarios: one for quantity less than zero, one where the quantity requested is greater than the stock on hand, and another when the quantity requested can be satisfied.

In general, whenever a value is tested so it falls into several ranges, as above, each possible outcome leads to a different path and, therefore, to a different scenario.

Another source of scenarios is the current state of the objects involved. To establish the initial state for state machine instances, examine the statechart diagram to find the state that meets the preconditions. In the Order statechart diagram in Figure 15.2, the precondition "The order… is not expired and is not yet checked out" can be satisfied by exactly one state, Adding Selection to Order.

Figure 15.2. Order Statechart Diagram

(For the purposes of this chapter, the example is drawn from the version of the bookstore models as presented at the end of Chapter 10: Communicating Objects. The principal classes used in this example Product, Order, and Product Selection are shown in the class diagram in Figure 15.3. These models do not include the separate shopping cart or the assigner. The creation and execution of test cases against the complete set of bookstore models is left as an exercise to the reader.)

Figure 15.3. Product, Order, and Product Selection Classes

For the test case to be useful, we must also establish the expected result and verify that the models exhibit the desired behavior. The formal expression of the test case with specific values and expected outcomes is a test vector.

Definition: A test vector is a combination of system state, parameter values for an initiating signal, and an expected outcome by which we know whether the test passed or failed.

The test vector is the basis for automated testing. By specifying and injecting a test vector for each scenario and executing it with a verifier, we can ensure that each test case really does correspond to a use case, which we trust is a valid representation of some requirements.

For the example use case, Add Item to Order, there are two choices for the state of the system:

• only one related product selection

• many related product selections

and two choices for parameters of the initiating signal:

• product not already selected for the Order

• product already selected for the Order

Consequently, there are four distinct scenarios the product of the combinations of these choices. Using specific values for the use case described above, we can summarize the four test vectors in the Figure 15.4.

Figure 15.4. Four Different Test Vectors for a Single Use Case

The preconditions state what is required in order to get the expected results from the system. Such positive tests are important but are by no means a complete set of test cases. It is just as important to have negative tests that test the models to verify their behavior when some of the preconditions are not satisfied. After all, some real-world conditions are unanticipated and so will not meet the preconditions.

By testing values that don't match the preconditions, we can determine whether the models handle errors appropriately. We can also identify new requirements on the models and identify assumptions (requirements on lower-level domains) that can simplify the models.

These additional choices can be combined with other choices to create more test cases.

For Add Item, we can additionally test the following:

• a quantity of zero or less

• a quantity greater than the stock on hand

• an order that has already been checked out but payment was declined (state Payment Not Approved)

Error testing can quickly get out of hand and become overwhelming. In addition, it is sometimes not even possible to predict the expected output! Use your judgment on which tests to build and consider the value added by each new test.

The result of this work is some number of test vectors that can be executed.