Behavior Driven Development

Behavior Driven Development
Name	Behavior Driven Development
Acronym	BDD
Developer	Dan North; influenced by Test-driven development; associated with Cucumber (software), RSpec
Initial release	2003
Typing	methodology

Behavior Driven Development is a software development methodology that extends Test-driven development by emphasizing collaboration among stakeholders, developers, and quality assurance through ubiquitous language and executable specifications. It was introduced to improve communication between technical teams and business representatives, linking requirements to automated tests and living documentation. BDD influenced numerous tools and practices across the software engineering landscape, shaping processes at technology firms, consultancies, and open-source communities.

History

Behavior Driven Development emerged in the mid-2000s as a reaction to perceived limits of Test-driven development and practices popularized by figures like Kent Beck and Martin Fowler. It was articulated by Dan North while working at firms in the United Kingdom, drawing on ideas from Extreme Programming, Agile software development, and the Story Mapping techniques promoted by Jeff Patton. Early adopters included teams influenced by proponents such as Aslak Hellesøy and David Chelimsky, who built tools that operationalized BDD concepts. Over time, BDD intersected with movements led by organizations like ThoughtWorks, Pivotal Labs, and Red Hat, and was discussed at conferences like Agile2010, Velocity Conference, and QCon. Academic and industry analysis referenced case studies from companies such as Google, Microsoft, Amazon (company), Facebook, and Netflix (service).

Principles and Practices

Core principles of BDD draw from the manifesto-like guidance of Extreme Programming and the iterative values of Agile Alliance. Practices include using a shared vocabulary to reduce miscommunication among product owners, designers, and developers, often inspired by patterns from Domain-driven design advocates like Eric Evans and Vaughn Vernon. Teams adopt specification formats that map to acceptance criteria used by professionals from Quality Assurance and Product Management. Common practice recommends writing scenarios in Given–When–Then form, influenced by storytelling techniques popularized at XP Summit and shared at meetups organized by groups such as ACM and IEEE Computer Society chapters. BDD encourages living documentation and continuous verification aligned with continuous integration systems developed by firms like Jenkins (software), Travis CI, and CircleCI.

Workflow and Tools

A typical BDD workflow integrates collaboration tools and automation frameworks. Teams capture requirements as executable specifications using frameworks like Cucumber (software), SpecFlow, JBehave, and RSpec, often stored alongside code in repositories managed by GitHub, GitLab, or Bitbucket. Automation ties into CI/CD pipelines orchestrated with Jenkins (software), Azure DevOps, or GitHub Actions. Supporting tools include reporting and living documentation platforms maintained by Atlassian, Confluence (software), and Read the Docs-style systems. For behavior specifications, many teams employ language libraries maintained by communities around Ruby (programming language), Java (programming language), C#, JavaScript, and Python (programming language), integrating test runners like JUnit and NUnit. Security and compliance checks are often added via integrations with services from SonarSource, Snyk, and WhiteSource.

Specification by Example

Specification by Example, promoted by practitioners from Gojko Adzic and consultant firms such as ThoughtWorks, emphasizes using concrete examples to define requirements. Teams create executable scenarios that serve both as acceptance tests and documentation, a practice echoed in works presented at Lean Startup events and workshops led by Martin Fowler. Example-driven specifications reduce ambiguity when stakeholders from Product Owner roles, user experience teams associated with IDEO, and customer-success groups from companies like Salesforce participate in discovery. These examples are managed through collaboration platforms like JIRA and translated into automated steps by tools such as Cucumber (software) and SpecFlow.

Benefits and Criticisms

Proponents cite improved communication among practitioners from Product Management, UX design firms like Frog Design, and engineering teams at companies such as Spotify (service) and Etsy, Inc.. Benefits reported in case studies at conferences like O'Reilly Velocity include clearer acceptance criteria, reduced rework, and better alignment with business goals championed by Chief Product Officers at startups and enterprises. Critics, including some contributors to discussions in Stack Overflow and articles in IEEE Software, argue that BDD can be misapplied, producing brittle test suites or excessive maintenance overhead when scenarios are overly implementation-focused. Other concerns raised by analysts at Gartner and Forrester Research include cultural adoption challenges in organizations structured like legacy IBM divisions or Accenture practice groups.

Adoption and Industry Use

BDD has been adopted across a spectrum of organizations from startups to multinational corporations. Tech companies such as Amazon (company), Google, Microsoft, and Facebook have influenced BDD tooling and practice through open-source contributions and internal patterns. Consultancies like ThoughtWorks, Pivotal, and Capgemini have promoted BDD in client engagements, while financial institutions including Goldman Sachs and JPMorgan Chase have experimented with behavior-driven approaches for regulatory and trading systems. Education initiatives at universities affiliated with MIT, Stanford University, and Carnegie Mellon University have examined BDD in software engineering curricula. Community support is active in meetups hosted by organizations like Meetup (website), conferences including QCon, and online forums such as Stack Overflow.

Category:Software development methodologies