1 What is BDD?

Behavior-Driven Development is presented as a way to connect software delivery more closely to real business needs by treating development as an ongoing conversation among stakeholders, users, and the delivery team. Rather than seeing software work as just writing code, the chapter frames it as capturing intent in a precise, testable, and useful form that can guide implementation and keep the team aligned as understanding evolves.

The chapter explains that many software problems come from three recurring gaps: requirements that are too vague or incomplete, documentation that cannot be trusted to reflect what was actually built, and feedback that arrives too slowly or too unreliably to help teams steer effectively. BDD is introduced as a refinement of test-driven development that keeps requirements, examples, documentation, and implementation linked together, while also making room for collaboration with business people and meaningful support for maintainability.

BDD is described as working through three core practices: discovery, where the team explores a story through examples; formulation, where those examples are turned into clear, business-readable scenarios; and automation, where the scenarios become executable tests that provide fast feedback and living documentation. The chapter also warns against common adoption mistakes such as isolating automation from the business, writing unreadable scenarios, or treating BDD as a silver bullet, and it recommends introducing it gradually through collaboration, small experiments, and attention to context.

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

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

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.

BDD acts as a bridge that connects stakeholder requirements to the implementation delivered

• Modern software development processes suffer from incomplete requirements, unreliable documentation, and slow feedback.
• Behavior Driven Development (BDD) is an agile approach to developing software that provides the missing link between what the business needs and the software being developed.
• The three core practices of BDD are discovery, formulation, and automation.
• Discovery is a structured, collaborative activity that uses examples to discover the detailed requirements of a user story.
• Formulation is a creative process that turns the examples produced during discovery into business-readable scenarios.
• Automation is when code is written that turns the scenarios into tests.
• 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.
• AI will not result in BDD becoming irrelevant, because specifications still need to be provided by skilled domain experts.
• BDD adoption is challenging, but there are techniques that can help an organization succeed.

FAQ