BDD
Behavior-Driven Development (BDD) is an agile software development methodology where teams collaborate to define system behavior using natural language. These descriptions, often in a Given-When-Then format, guide development and are automated to become living documentation and acceptance tests.
First used·2006
Definitions·1
Synonyms·2
Category·Software Development
Also known as
Definitions
What it means.
- 01
Behavior-Driven Development in Software Engineering
Behavior-Driven Development (BDD) is an agile software development process that encourages collaboration among developers, quality assurance testers, and business participants in a software project. It extends Test-Driven Development (TDD) by writing test cases in a natural, human-readable language that focuses on the behavior of the system from the user's perspective.
The core of BDD is the concept of creating a ubiquitous language that is shared by all team members, including non-technical stakeholders. This language is used to write specifications for the system's behavior. These specifications are often called 'scenarios' or 'features' and are written in a structured format, most commonly Gherkin's
Given-When-Thensyntax.Example of a BDD Scenario (Gherkin):
Feature: User Authentication Scenario: Successful login with valid credentials Given the user is on the login page When they enter a valid username and password And they click the 'Login' button Then they should be redirected to their dashboardThis process follows an 'outside-in' approach. The team first defines the desired behavior from the outside (the user interface or API level) and then works inward to implement the functionality that produces that behavior. These human-readable scenarios are then automated, serving as both living documentation and an acceptance test suite.
Origin
Where it comes from.
Etymology
The term 'Behavior-Driven Development' was coined by Dan North in 2006. It was created as a response to the challenges he observed with Test-Driven Development (TDD). He wanted to shift the language from 'test' to 'behavior' to make the process more accessible to business analysts and other non-technical stakeholders, emphasizing that the goal was to specify behavior, not just to test code.
Historical context
BDD emerged from the agile software development community as an evolution of Test-Driven Development (TDD) and Acceptance Test-Driven Development (ATDD). In the early 2000s, TDD was gaining popularity, but practitioners like Dan North found that developers often struggled with what to test and how to name their tests. The focus was too much on the implementation (the 'how') rather than the desired outcome (the 'what').
In 2006, Dan North published the seminal article "Introducing BDD," which proposed shifting the vocabulary from tests to behaviors. This simple change in perspective aimed to bridge the communication gap between technical teams and business stakeholders. Shortly after, tools began to appear to support this new practice. Dave Astels and Aslak Hellesøy created RSpec, a BDD framework for Ruby, and Hellesøy later created Cucumber, which popularized the Gherkin Given-When-Then syntax. Cucumber's ability to parse plain text specifications made BDD accessible to a much wider audience and led to its widespread adoption across various programming languages and platforms.
Usage
In context.
Our team adopted BDD to ensure that both the developers and the product owner had a shared understanding of the new feature's requirements.
By writing our acceptance criteria using Behavior-Driven Development principles, we created executable specifications that also served as our automated regression suite.
The QA engineer facilitated a Specification by Example session, a core practice of BDD, to flesh out the edge cases for the user login story.
FAQ
Common questions.
The primary goal of BDD is to improve communication and collaboration among developers, testers, and business stakeholders. It aims to create a shared understanding of how an application should behave from the user's perspective, using a common, human-readable language. This shared understanding is then used to guide development and create executable specifications.
Taxonomy
Filed under.
Categories
Tags