A requirement can sound clear until someone asks what should happen in a particular case. Specification by example uses concrete situations to help users and developers agree on the behavior they want. It belongs to the same family of practices as acceptance test–driven development and behavior-driven development (BDD). Where practical, teams can turn agreed examples into automated acceptance criteria before building a feature. section 2.2
Given a customer has a current account When the customer transfers funds from this account to an overseas account Then the funds should be deposited in the overseas account And the transaction fee should be deducted from the current account
The account-transfer scenario makes the expected deposit and transaction-fee deduction explicit. Its Given–When–Then form can also serve as the basis for an automated acceptance criterion. section 2.2
Shared examples and implementation tests work at different scales. BDD focuses the team on business goals, features, and scenarios; test-driven development (TDD) uses smaller examples to work out classes, methods, and APIs. An automated acceptance criterion may require many unit tests before it passes. In the TDD loop, write a failing test, add enough code to pass it, then consider refactoring. section 3.5.4
Make a departure-time example self-contained
Suppose a journey request is made at 8:25 and the expected next train is at 8:30. Without a stated timetable, the expected result is hard to justify. Setting up departures at 8:10, 8:20, and 8:30 makes the rule visible: the first departure after the requested time is 8:30. section 3.5.4
