"Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software development and management teams with shared tools and a shared process to collaborate on software development." - Behavior-driven development
Behavior Driven Development (BDD), also referred to as Acceptance Test Driven Development (ATDD), is a collaboration process meant to create a shared understanding among team members around a unit of work. A covenant is created between the business and engineering using a common interface, gherkin. The intention is to deliver high-quality software that meets desired business outcomes the first time.
Once the covenant is ratified, the engineer begins work to meet the specification. The system behavior is solidified by codifying the scenarios through automation.
The ten minutes of video below further elaborate the benefits, process, and specifics of gherkin.
Testimonial about the benefits of BDD.
Overview of BDD process.
Overview of Gherkin
Gherkin Syntax Reference:
Given <context>
When <event>
Then <outcome>
Top comments (2)
In my experience, the primary benefit of BDD is facilitating communication between the product manager, the business analysts, the developers, and the quality engineers.
Providing an English-like way to express specifications in a language like Gherkin enables the product manager and business analysts to write the behavior in a way that can actually be exercised in an automated fashion.
Which brings the PM & BAs to the table, instead of having a requirements specification that needs to be converted into code, one step removed from the PM & BA domain.
Obviously, for something like Gherkin, the developers still have a lot of work to do to create the infrastructure for the Gherkin written stories to be exercised. Over time, as an emergent property, a large vocabulary of nouns, verbs, and state queries allow the PM & BAs to put together more interesting stories expressing requirements specification. It's a virtuous cycle.
But still, that key benefit of getting everyone at the table to discuss and refine the stories in Gherkin becomes a communication facilitator.
The only two times I've seen BDD fail is, 1) if the PM abdicates responsibility for creating and maintain the BDD stories and puts that effort on the developers, or 2) BDD is used as a mechanism for quality engineers to write integration and acceptance tests instead of a PM tool for expressing requirements.
I agree, the collaboration between the nerds and the business is the primary benefit.
Even if the gherkin is not automated, which is a silly thing to not do, value is gained through shared expectations.