2 Introducing Behavior-Driven Development

In this chapter we will dive into what BDD looks like in a little more detail. BDD is a set of software engineering practices designed to help teams build and deliver more valuable, higher-quality software faster. It draws on Agile and lean practices, including in particular, Test-Driven Development (TDD) and Domain-Driven Design (DDD). But most importantly, BDD provides a common language based on simple, structured sentences expressed in English (or in the native language of the stakeholders) that facilitate communication between project team members and business stakeholders. To better understand the motivations and philosophy that drive BDD practices, it’s useful to understand where BDD comes from.

2.1 BDD was originally designed to make teaching TDD easier

BDD was originally invented by Daniel Terhorst-North¹ in the early to mid-2000s as an easier way to teach and practice TDD, which was invented by Kent Beck in the early days of Agile.² TDD is a remarkably effective technique that uses unit tests to specify, design, and verify application code.

2.2 BDD also works well for requirements analysis

2.3 BDD principles and practices

2.3.1 Focus on features that deliver business value

2.3.2 Work together to specify features

2.3.3 Embrace uncertainty

2.3.4 Illustrate features with concrete examples

2.3.5 A Gherkin primer

2.3.6 Don’t write automated tests; write executable specifications

2.3.7 These principles also apply to unit tests

2.3.8 Deliver living documentation

2.3.9 Use living documentation to support ongoing maintenance work

2.4 Benefits of BDD

2.4.1 Reduced waste