Real-world cases are messy, which is half the fun. Behavior-driven development (BDD) scenarios for a real case have to catch the rush, the refund and the declined card as well as the tidy path. Twelve steps keep them accurate: four before you write, six as you write and two before work starts.
Before you write
1. Understand the real-world case
Know the case cold before writing a scenario: its user stories, its use cases and the domain knowledge behind them. Name the specific problem or need the software is there to address.
2. Identify user roles
Name every user role or persona the case involves. The customer placing an order and the owner filling it meet the same order in different ways, and each gets scenarios of their own.
3. Define high-level scenarios
Sketch the case’s key interactions or processes as a few high-level scenarios first. They are the frame the detailed scenarios hang on.
4. Name the scenarios
For each high-level scenario, list the smaller scenarios it holds by name, one behavior each, before writing any steps.
As you write
5. List user actions (When)
List what users actually do in the case, such as entering data, making a decision or exchanging messages with the software.
6. Describe the initial state (Given)
The Given describes the state before the user acts: the scenario’s preconditions, such as data already in place, a system started up or a user signed in.
7. Define the expected outcomes (Then)
The Then says what should happen once the user acts in this case: what a selector returns, what an endpoint answers, or the data that changed.
8. Consider alternate paths
Real cases branch. Wherever the software can behave differently, that path gets a scenario of its own. A declined card is an expected failure, not an exception; the lecture Practical Applications of Functional Programming represents such failures as plain data a test can check.
9. Use natural language
Write in natural language that technical and non-technical team members both read easily. The jargon stays in the code.
10. Include edge cases
Probe the edges: boundary conditions, and inputs that are unusual or unexpected. Each gets a scenario.
Before work starts
11. Review and revise
Read the set again for clarity, accuracy and completeness: does it describe the case as it really happens, with the behavior users expect?
12. Read them with people who know the trade
Read the scenarios with the owner, the people who use the result and anyone who knows the trade, before work starts. They know the cases a scenario misses: the rush, the refund, the regular who orders by phone.
Example BDD scenario for a real-world case
Here is a real case, an online order, in three scenarios:
Feature: Checkout
Scenario: Choosing where the order ships
Given Ada has two saved addresses
When she chooses her work address at checkout
Then the order ships to her work address
Scenario: Placing the order
Given Ada's cart holds "Widget A" at $25
And she has chosen an address and a card
When she places the order
Then the order is recorded at $25
And her cart is empty
Scenario: Confirming the order
Given Ada's account email is "ada@example.com"
When she places the order
Then a confirmation email goes to "ada@example.com"A first draft put four behaviors under one When (choosing the address, choosing the card, placing the order and sending the confirmation); split into three scenarios, with the chosen card a Given of the second, each When names one event and each failure names one behavior.
Worked this way, a messy case becomes a clear, testable specification of how the software should behave when real life gets complicated, in words the owner can check against the business. Reviewing and enhancing BDD scenarios as a group, next, hands them to other readers and catches the scenario that quietly tests nothing.