A requirement such as “show the next train” can hide important questions: which line, which direction, and how many departures? Given/When/Then turns a concrete example into a scenario that stakeholders, testers, and developers can examine together. Writing it often exposes assumptions before implementation begins. section 3.4 section 2.3.4
A scenario separates three concerns:
- Given describes the relevant starting state or preconditions. section 7.2.3
- When names the action or event being tested. section 7.2.3
- Then states the expected result. section 7.2.3
Transfer between accounts
Given a client has $1,000 in a current account and $2,000 in savings; When she transfers $500 from current to savings; Then the balances are $500 and $2,500 respectively. The amounts make the expected behavior discussable and checkable. section 2.3.4
Include preconditions that affect the business result, but avoid burying the goal in setup detail. For a booking change with no additional charge, Frequent Flyer membership may matter; a login step may not explain that rule. Extend a clause with And or But when needed, and split distinct conditions or outcomes into focused steps. section 7.2.3 section 7.2.4
Feature: Earning Frequent Flyer points from flights
Scenario: Flights within Europe earn 100 points
Given Tara is a Frequent Flyer traveler
When she completes a flight between Paris and Berlin
Then she should earn 100 points
This complete scenario makes a points rule concrete: traveler status supplies the context, completing a flight is the event, and earning 100 points is the expected result. section 7.1
Keep scenarios readable as living documentation, not merely as test scripts. Tables can reduce repetition or present test data and results. BDD tools such as Cucumber and SpecFlow can execute structured scenarios as acceptance tests and produce reports in business-facing terms. section 7.0 section 7.1
