1 What is BDD?

Software development is presented as a social and technical conversation, not just a coding exercise. The chapter argues that teams often struggle because requirements are incomplete, documentation becomes unreliable, and feedback arrives too slowly to prevent rework and defects. These problems create gaps between what stakeholders want, what teams build, and what the system is actually expected to do.

Behavior-Driven Development is introduced as a way to close that gap by connecting requirements, examples, documentation, tests, and the implemented system. It centers on three practices: discovering detailed requirements through collaborative examples, formulating those examples into business-readable scenarios, and automating the scenarios so they guide implementation and act as living documentation. BDD grew from TDD, but it shifts the emphasis toward shared understanding and business engagement while still relying on strong technical discipline.

The chapter also warns that BDD is often misunderstood or adopted poorly. Common mistakes include treating it as a naming fad, using it without real business involvement, isolating automation from development, or producing unreadable scenarios and fragile code. Successful adoption is framed as gradual and collaborative: start small, improve how roles work together, and use BDD as a practical bridge between stakeholders and delivery teams rather than expecting it to solve every problem instantly.

BDD is an agile approach to delivering software that introduces three core practices

The TDD cycle starts by writing a test and seeing it fail (Red). Then we write just enough code to have the test pass (Green). Finally, we refactor the code to improve its structure

The BDD cycle is the outer loop – write a failing scenario, get the scenario to pass, then refactor. We enter the inner, TDD cycle to implement the code needed to move from a failing scenario to a passing scenario.

• Modern software development processes suffer from incomplete requirements, unreliable documentation, and slow feedback.
• Behavior Driven Development (BDD) maintains the connection between the requirements and the software by using examples that describe how the system should behave. These examples are called scenarios when expressed in business language.
• There are many tools that can interpret scenarios and directly execute them as tests of the software being developed.
• Each user story describes several rules. Each rule should be illustrated by one or more scenarios, and each scenario helps us explore our understanding of the rule.
• BDD follows the same Red/Green/Refactor cycle as TDD, but at the level of the scenario. Developers use the TDD cycle when getting a failing scenario to pass.
• BDD does not remove the need for traditional software testing, but it reduces the team’s reliance on it by ensuring that most misunderstandings are dispelled before any code is written.
• By collaborating on the creation of the scenarios, the team creates documentation that can be understood by all stakeholders.
• Scenarios, when run as tests, become living documentation of the software that is being built. Living documentation automatically informs the team when the software implementation diverges from the behavior documented by the scenarios.
• BDD is an agile approach to developing software, consisting of three practices: Discovery, Formulation, and Automation.
• BDD adoption is challenging, but there are techniques that can help an organization succeed.

FAQ