Behavior-Driven Development
Dan North coined the term in 2003 as an evolution of TDD, observing that the main problem with TDD was not technical but one of communication: developers did not know what to test, and technical tests were not readable for business stakeholders.
The Given/When/Then format
BDD structures each behavior scenario into three clauses:
- Given: the initial state of the system or the context in which the action takes place.
- When: the action performed by the user or the system.
- Then: the expected result, which can be verified.
Example:
Given that the user is logged in and has sufficient balance,
When they transfer €100 to another account,
Then their balance is reduced by €100 and the transaction appears in the history.
This scenario can be written by the Product Owner or the business analyst, reviewed by the technical team, and run automatically by a BDD tool such as Cucumber or Behave.
- Benefits ==
Wait — correct output: == Benefits ==
- Shared language: BDD scenarios are understandable to both business stakeholders and developers, reducing misunderstandings in the acceptance criteria.
- Living documentation: scenarios are both specification and test: when the code changes, the tests detect whether the expected behavior has changed as well.
- Value-oriented coverage: BDD tests focus on what matters to the user, not on technical implementation details.
- It facilitates SDD: Given/When/Then scenarios are a form of spec readable by both people and AI agents.
BDD and AI
BDD has direct synergy with AI-assisted development:
- Given/When/Then scenarios can be used as a specification for an AI agent to generate the code that satisfies them: the test precedes the code, just as TDD prescribes.
- Scenarios written by the team in natural language are more resistant to hallucinations than purely technical specs, because they are anchored in verifiable user behaviors.
- AI tools can help turn user stories into BDD scenarios, although human review of edge-case coverage remains essential.
Common mistake
Using BDD only as a technical testing tool, ignoring the shared language. The value of BDD does not lie in Cucumber or Gherkin: it lies in business people and technical people collaborating to define behavior before building it. If the Given/When/Then scenarios are written solely by the technical team without the participation of the Product Owner or the users, BDD becomes TDD with different syntax.
Resources
📄 Scrum Master en equipos con IA v.1.0 (Scrum Master in Teams with AI v.1.0, in Spanish)Free download · Scrum Manager
References
- North, Dan. (2006). "Introducing BDD". dannorth.net.
See also
Want to move forward in agility? You can look for course and exam calls or go at your own pace by becoming a member of the Agile Club. This membership includes exclusive resources, e-learning classrooms, and access to Skill Arena: a space to practice and measure your agile skills at your own pace.