BDD: Describing behaviour in everyday language (Given – When – Then)

In short: Behaviour-driven development describes desired behaviour in understandable scenarios following the given – when – then pattern; the scenarios are requirement, documentation and automatic test at once.

In more detail: BDD extends TDD: instead of technical test names, domain experts, testers and developers write examples in everyday language together. This creates a shared understanding before programming, and the examples later run as tests.

In Depth

The pattern: given – when – then

Feature: Shopping cart
  Scenario: Redeem voucher
    Given the cart contains items worth 50 euros
    When I redeem the voucher "SUMMER10"
    Then the total is 45 euros

• Given: starting situation.
• When: action or event.
• Then: expected result. The language is called Gherkin (.feature files). Scenarios are concrete (real numbers, real examples), not abstract.

Tools

Cucumber (many languages), Behave and pytest-bdd (Python), SpecFlow/Reqnroll (.NET), Cypress/Playwright with Cucumber. Each sentence is mapped to a step definition (code) that drives and checks the application. Even without a tool the thought structure is useful: precondition, action, result in tests and requirements.

Three amigos and examples

Good BDD practice begins with the conversation (“three amigos”: business, development, test): which rules exist, which examples and edge cases? Open questions become visible early, misunderstandings are cheap to fix. The scenarios serve as living documentation that never goes stale because it runs.

Limits and tips

• Not every project needs Gherkin; the overhead pays off when domain experts read and co-write the scenarios.
• Keep scenarios short (3 to 7 steps) and one behaviour per scenario.
• No UI details (“click button #3”), but intent (“order the item”).
• At E2E level slow: only important paths; details as unit tests.
• Combination: TDD for code, BDD for requirements.

See also: Test-driven development, Types of testing, Playwright, Requirements and specification documents