Behavior-driven development
Behavior-driven development (BDD) is a way of building software in which the team writes the expected behavior of a feature as concrete examples in plain language before implementing it, in the form Given a starting context, When an action happens, Then an outcome follows, and then automates those examples so they run as tests. The scenarios are the specification and the acceptance test at once.
The longer version
The mechanism is the shared example. A product owner, a developer and a tester sit with a user story and write down specific situations: Given a customer with an expired card, When they confirm the order, Then the order is declined and the card form is shown. Each scenario is stored in a feature file, and step definitions map each line to code that sets up the context, performs the action and asserts the outcome. The scenarios fail until the feature exists, pass when it does, and stay in the suite as regression checks and as documentation that cannot drift from the code, because it runs against it.
Test-driven development works at the unit level and is a developer's rhythm: write a failing test for a small piece of code, make it pass, refactor. BDD works at the feature level and is a conversation before it is a test. Acceptance test-driven development is the closest neighbor and shares the sequence of writing acceptance tests first; BDD adds the Given/When/Then form and the insistence that non-developers can read and write the scenarios. Acceptance criteria are the raw material: BDD turns each criterion into examples precise enough to execute.
Scenarios written by developers alone after the code exists are the commonest decay: the feature files describe the implementation in stilted English and never involve the product owner, so the conversation that was the point never happens. The second decay is the scenario that reads like a UI script, click this button, enter this text, which breaks on every layout change and tests the screen rather than the behavior. A useful scenario names business outcomes and survives a redesign.
Common questions
What is the difference between BDD and TDD?
Test-driven development is a developer's loop at the unit level: a failing test for a small piece of code, then the code, then a refactor. Behavior-driven development works at the feature level and starts with a conversation between product, development and testing that produces plain-language scenarios, which are then automated. Teams often use both, BDD for features and TDD inside them.
Who writes BDD scenarios?
The three roles together: whoever owns the requirement, whoever will build it and whoever will test it. The product owner supplies the examples that matter to the business, the tester probes for the edge cases, and the developer keeps the scenarios expressible in code. Scenarios written by one role alone lose the shared understanding that justifies the ceremony.
Do you need a BDD tool to do behavior-driven development?
The practice is the collaborative writing of examples before implementation; the tools that parse Given/When/Then files and bind them to code make those examples executable. A team can hold the conversation and write the examples as ordinary tests, and a team can install the tool and skip the conversation. Only the first is BDD.
How does a BDD scenario become an executable test?
Each line of the scenario is matched to a step definition, a small function that sets up the Given context, performs the When action or asserts the Then outcome. A tool such as Cucumber reads the feature file, runs the matching functions in order and marks the scenario failed at the first step that does not hold, so a scenario with no step definitions behind it is documentation only.
What does BDD look like in an agile team?
The scenarios are written during backlog refinement, when product, development and testing meet over a story before the sprint starts. They are automated early in the sprint and fail until the feature is built. The story is done when the scenarios pass, so the sprint review shows running examples rather than a demonstration, and the scenarios stay in the suite as regression checks.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.