Scenarios are where behavior-driven development (BDD) turns a user story into checks. Each one pins down, in Given-When-Then form, how the software should behave in one situation, seen from where the user stands. Nine habits make them good.
1. Understand the feature or user story
Start from the user story and its acceptance criteria, as the written scope names them. Each criterion becomes one or more scenarios, so know which behavior a scenario is for before writing its first line.
2. Use the Given-When-Then format
Every scenario has the same three parts, which keeps it clear and short:
- Given: the context or state of the system before the behavior under test; the test’s preconditions.
- When: the action or event under test, usually the user’s, sometimes something outside the system.
- Then: the outcome the When should produce.
3. Be specific and concrete
Name real values: a product, a price, a balance. “The cart total is $25” leaves nothing to argue about, and “the cart looks right” leaves everything. The more precise a scenario, the easier it is to understand and to build.
4. Use plain language
Write in the owner’s own words for the business, which technical and non-technical team members read the same way. The jargon stays in the code.
5. Include context in the “Given” section
The Given sets the stage: the state of the system, and anything else the scenario needs to make sense. For example:
- Given the user is signed in
- Given the user has a balance of $100 in their account
6. Describe actions in the “When” section
The When is the action or event under test, usually something a user does. For example:
- When the user deposits $50
- When the user signs in with the correct password
On the Sean Dinwiddie’s Webmastery team, each When names one event, the same event a Redux Toolkit slice’s reducer handles, and each Then names what a selector or an endpoint returns, so most scenarios run below the interface.
itemAdded), and the Then checks what a selector (or an endpoint) returns, so no screen is needed.7. Define expected outcomes in the “Then” section
The Then states what the When should produce: the behavior under test. For example:
- Then the statement lists a $50 deposit
- Then the account balance is $150
8. Keep scenarios small and focused
One scenario, one behavior: a single user interaction, tested on its own. A small scenario is easy to understand, to build and to keep, and when it fails, you know which behavior broke.
9. Group the criteria under Rules
When a Feature holds more than one of the criteria from step 1, Rules can group them, each holding the scenarios that test it, so every scenario sits under the criterion it tests and a failure leads straight to it; a Feature with one criterion, like the cart below, needs none.
Example BDD scenario
Here is one for an online shop’s cart:
Feature: Cart
Scenario: Adding a product to the cart
Given "Widget A" is in stock at $25
And the cart is empty
When the customer adds "Widget A" to the cart
Then the cart contains "Widget A"
And the cart total is $25It says what should happen when a customer adds a product to the cart. Its When is the event a cart slice would name itemAdded; the lecture Redux Toolkit and RTK Query Best Practices names actions after events the same way. Module 4’s From scenario to slice follows it into a slice and its test.
With these habits, each scenario says, in the user’s terms, exactly how the software should behave, and each becomes a test that fails when the software stops doing what its users expect. Writing BDD scenarios for software modules, next, scopes them to one module, in eleven steps, so a failure points to one place.