Behavior-driven development (BDD) involves naming software tests using domain language to describe the behavior of the code.
BDD involves use of a domain-specific language (DSL) using natural-language constructs (e.g., English-like sentences) that can express the behavior and the expected outcomes.
Proponents claim it encourages collaboration among developers, quality assurance experts, and customer representatives in a software project.
[1][7] At a high level, BDD is an idea about how software development should be managed by both business interests and technical insight.
Acceptance criteria should be written in terms of scenarios and implemented in classes: Given [initial context], when [event occurs], then [ensure some outcomes] .
TDD does not differentiate tests in terms of high-level software requirements, low-level technical details or anything in between.
The scenario aspect of this format may be regarded as an application of Hoare logic to behavioral specification of software using the domain-specific language.
BDD suggests that business analysts and software developers should collaborate in this area and should specify behavior in terms of user stories, which are each explicitly documented.
[5] It also suggests that the scenarios should be phrased declaratively rather than imperatively — in the business language, with no reference to elements of the UI through which the interactions take place.
BDD requires not only test code as does TDD, but also a document that describes behavior in a more human-readable language.
Proponents suggest that due to its human-readable nature the value of those documents extends to a relatively non-technical audience, and can hence serve as a communication means for describing requirements ("features").
The ubiquitous language allows business analysts to document behavioral requirements in a way that will also be understood by developers.
The principle of BDD support tooling is to make these same requirements documents directly executable as a collection of tests.