Acceptance Test-Driven Development Behavior Driven Development Home Page

Acceptance Test-Driven Development / Behavior Driven Development involves a triad: the customer, developer, and tester. The power of three people working together can create a shared understanding expressed with descriptions of behavior that form acceptance tests. If the triad writes the tests together, the distinction between user acceptance tests and system tests is practically eliminated. The three roles of customer, developer, and tester may be played by different individuals or by the same individual with different focuses or a group of people taking on those perspectives.

The Triad

The customer who provides the requirements
The developer who implements the requirements
The tester who critically analyzes the requirements and the implementation

Benefits

Here is a summary of ATDD/BDD benefits. It's in the Given-When-Then format which is a popular way of expressing scenarios and tests.

Given current conditions like these:

No detailed requirements
Unclear business rules
Poorly defined acceptance criteria
Not enough testers
Defects hold up deployment
Development team not understanding business process

When Acceptance Test-Driven Development / Behavior Driven Development (ATDD/BDD) is added

Then you can get the following results:

Tests for details of requirements
Getting business rules right
Crisp visible story completion criteria
Tighter cross-functional team integration
Rework down from 60% to 20%
Workflows working first time

Background

A Chinese proverb says, “There are many paths to the top of the mountain, but the view is always the same.” And many of the paths share the same trail for portions of the journey. Although acceptance testing has been around for a long time, it was reinvigorated by extreme programming . Its manifestations include ATDD as described in Lean-Agile Acceptance Test-Driven Development by Ken Pugh, example-driven development (EDD) by Brian Marick, behavior-driven development (BDD) by Dan North, story test-driven development (SDD) by Joshua Kerievsky of Industrial Logic, domain-driven design (DDD) by Eric Evans, and executable acceptance test-driven development (EATDD). All these share the common goal of producing high-quality software. They aid developers and testers in understanding the customer’s needs prior to implementation and customers being able to converse in their own domain language.