BDD

Behaviour-Driven Development is the practice of describing what software should do in the vocabulary of the people who asked for it — and then executing that description.

It is a collaboration technique that happens to produce tests, not a testing technique that happens to involve the business. Teams that get this backwards end up with Given I click the button with id submit-btn, which is a test with a costume on.

The shape

Feature: Overdraft protection

  Scenario: A payment that would exceed the agreed overdraft is declined
    Given an account with a balance of -450 CHF
    And an agreed overdraft limit of 500 CHF
    When a payment of 80 CHF is presented
    Then the payment is declined
    And the account balance is unchanged

Three things to notice. The steps name domain concepts, not UI elements or database tables. The values are concrete — they came from a green card in example mapping. And the scenario would still make sense read aloud to someone from the business who has never seen the codebase.

The ubiquitous language

The vocabulary in these scenarios is the same vocabulary used in the code, in the event catalogue and in the C4 model. When a scenario needs a word the code does not have, one of the two is wrong, and that is worth finding out.

Where the scenarios come from

Not from a analyst writing them alone. They come out of example mapping, where the room agreed on the examples. Writing them afterwards is transcription; writing them instead of having the conversation is the anti-pattern that gives BDD its bad reputation.

Where they live

In a .feature file in the repository, beside the code it specifies — not in a wiki and not in a ticket description. The file is the digital artefact example mapping emits, and the Rule: keyword maps directly onto the blue cards, so the wall and the executable specification are the same thing in two media.

Where they go

Straight into ATDD: the scenario becomes the failing acceptance test that drives the implementation, and stays as the regression net afterwards.

They also decide the shape of the board. A scenario is the smallest unit anyone can be shown, so it is the unit a ticket is built from — a subset of whole scenarios, never a fraction of one.

What executes them

Cucumber, attached at the use case port rather than at the browser — the single decision that most determines whether the suite survives.

The honest caveat

Gherkin has a real cost — a step definition layer to maintain, and a temptation to reuse steps until they grow parameters nobody understands. It earns that cost only when non-developers actually read the scenarios. If nobody outside the team ever opens them, write the same examples as plain acceptance tests and keep the conversation.