Use Case Foundation and BDD/ATDD
Ken Pugh (ken@kenpugh.com)
The Use Case Foundation[1] article defines use cases and the principles behind them and gives an example of use case[2]. This article shows the relationship between a use case and Behavior Driven Development / Acceptance Test-Driven Development (BDD/ATDD) scenarios.
A use case represents the big picture. From the article, “A use case is all the ways of using a system to achieve a goal of a particular user.” “A use case tells the whole story, as a story, from the initial event to the realization of the value it provides or the eventual failure if it can’t be met.” It includes many instances of “flow of events.”
Scenarios
BDD/ATDD scenarios represent testable flows. A scenario can depict an entire flow, but typically each describes a small portion of a flow. Scenarios are more detailed than a use case. They usually include data which is entered, calculated, or output from the flow. The data can be used during testing of the scenarios.
Let’s use the example in the Use Case article as the base for showing how it would be transformed into scenarios. The example is:
Scenarios have a Given/When/Then format. A template is:
Given the current state,
When an event or action occurs,
Then there is a new state, an output, or both.
Main Flow Scenario
You could translate the main flow of the use into a scenario by applying the preceding template. The following scenario encompasses the entire flow, so it has multiple Whens for the Shopper actions. Scenarios usually have only a single When clause, so this scenario would be broken up into multiple scenarios, as you’ll see shortly.
Scenario: Purchase a Product
Given Shopper wants a product
When Shopper browses for a product
And when Shopper selects a product
And when Shopper provides payment details
And when Shopper provides delivery details
And when Shopper confirms purchase
Then product is scheduled for delivery
One might have a scenario with all the steps as the basis for an end-to-end test. To do so, data could be associated with each step. This data represents an example of the flow. The test checks that the output or state change in the Then step actually occurs.
Scenario: Purchase a Product
Given Shopper wants a product "Widget"
When Shopper browses for a product
| Name | Description | Price |
| Acme Widget | For medium use | $10.00 |
| Xyz Widget | For light use | $8.00 |
And when Shopper selects a product
| Name |
| Acme Widget |
And when Shopper provides payment details
| Type | Number | Expiration | CVV |
| Amex | 374245455400126 | 05/2026 | 1234 |
And when Shopper provides delivery details
| Street Address | City | State | Zip Code |
| 1 Penny Lane | Durham | NC | 27701 |
And when Shopper confirms purchase
Then product is scheduled for delivery
The test could be run using the same data on the internal business logic, and it could be run through the user interface. If the business logic test passed and the user interface test failed, one could start debugging by looking at the plumbing between the two.
Note that we might discover additional events that need to occur when we add the data. Payment information was provided in the flow, but never used. So, this step might be added to the end:
And credit card is charged.
Smaller flow scenarios
Typically, scenarios are for smaller portions of the flow. Each scenario consists of a single When step. The above scenario might be decomposed into steps such as:
Scenario: Determine a product
Given Shopper is browsing for a product
When Shopper selects a product
Then a Product is selected
and:
Scenario: Valid Delivery Details Provided
Given a Product is selected
When Shopper provides delivery details
Then Delivery details are recorded
Alternative Flows
Each of these small scenarios could have alternative ones. For example, there might be a scenario for “Determine a set of products,” which could involve selecting several products. Each of these smaller scenarios could have data associated with the steps, such as:
Scenario: Valid Delivery Details Provided
Given a Product is selected
When Shopper provides delivery details
| Street Address | 1 Penny Lane |
| City | Durham |
| State | NC |
| Zip Code | 27701 |
Then Delivery details are recorded
| Street Address | City | State | Zip Code |
| 1 Penny Lane | Durham | NC | 27701 |
Now the alternatives which are listed in the use case would have their own scenarios. For example, the alternative:
would have one or more scenarios that looked like this:
Scenario: Invalid Delivery Details Provided
Given Order in progress
When Shopper provides delivery details
| Street Address | 100 Penny Lane |
| City | Durham |
| State | NC |
| Zip Code | 27799 |
Then error is noted
| Street Address does not exist |
Every alternative would have at least one scenario associated with it. Business rules which may be discovered during use case formulation or scenario expansion could describe these alternatives. For example, for this alternative:
There might be a rule that determines how much of a product should be shipped if there were not enough in stock:
Business Rule Deliver Products in Stock
| Deliver | Product | Product | Product | Product | Notes |
| Partial | In Stock | Ordered | Backordered | Shipped | |
| Order | | | | | |
| No | 1 | 1 | 1 | 1 | Enough product |
| No | 1 | 2 | 0 | 0 | Not enough in stock |
| Yes | 1 | 2 | 1 | 1 | Backorder |
Summary
A use case which gives a big picture of all the flows forms a cohesive context for the BDD/ATDD scenarios that detail the steps of each of the flows.
[2] Use case from the article:
