Behaviour-Driven Development

Behaviour-driven development, commonly shortened to BDD, keeps development conversations focused on externally meaningful behaviour. Examples often use a Given, When, Then shape so developers, testers, and product colleagues can agree what success means.

Examples Before Implementation

A useful scenario names a starting state, one action, and observable outcomes. It avoids implementation detail such as method names or database table structure unless those details are the subject of the requirement.

BDD scenarios can become automated tests, acceptance criteria, or review prompts.

Keep Scenarios Concrete

"User can manage basket" is too vague. "Given a basket below the free-delivery threshold, when a customer adds an eligible product, then the delivery fee becomes zero" gives the team a testable rule.

Given a basket total of 4500 pence When a 700 pence product is added Then the delivery fee becomes 0 pence

That scenario can drive a fast service-level test. A separate browser journey is only needed if the user-facing display is also important.

Common Mistakes

• Writing scenarios so broad that several behaviours can fail at once.
• Encoding UI click-by-click detail when the business rule is the important part.
• Using BDD vocabulary without discussing examples with the team.
• Automating every scenario through the browser.

What To Practise

• Write concrete Given, When, Then scenarios.
• Separate business behaviour from UI implementation.
• Choose an automation boundary after agreeing the example.