Behavior-driven development
Behavior-driven development (BDD) is a practice, grown out of TDD, that describes how software should behave in plain, structured language shared by business and technical people. The same behavior descriptions do three jobs at once: they are the requirements, the automated tests, and living documentation. Its best-known shape is the Given / When / Then scenario.
It was introduced by Dan North around 2006 to fix a recurring problem: TDD works, but newcomers kept struggling with what to test and what to call things. BDD’s answer was to talk about behavior in a ubiquitous language that everyone shares.
Also known as
BDD · (British spelling) behaviour-driven development
Don't confuse with
- TDD: BDD is TDD refocused from the word “test” onto “behavior,” in language a non-programmer can read. TDD tends to be unit-level; BDD tends to be behavior/feature-level.
- ATDD: nearly the same goal (agree on acceptance examples first). BDD is often seen as the flavor that popularized the shared Given/When/Then language.
- Gherkin and Cucumber (the tools): Gherkin is the Given/When/Then syntax; Cucumber (and JBehave, SpecFlow) are tools that run it. They implement BDD; they are not BDD itself.
Given / When / Then
A scenario describes one concrete example of behavior:
- Given some starting context,
- When an action happens,
- Then an outcome is expected.
Example
Given I have items in my cart, when I apply a valid coupon, then the total drops by the coupon amount.
Because it reads as plain English, the same scenario is understood by the Product Owner, written once, and executed as an automated test.
See also
- Test-driven development: the practice BDD grew from
- Acceptance test-driven development: the closely overlapping idea
- User story: BDD scenarios flesh out a story’s acceptance criteria
References
- D. North, Introducing BDD (Better Software magazine, 2006). https://dannorth.net/blog/introducing-bdd/
- The Cucumber project, on BDD and the Gherkin syntax. https://cucumber.io/docs/bdd/