Konubinix' opinionated web of thoughts

Behavior-Driven Development

Fleeting

Like TDD, you make something emerge from the test. But in contrast to TDD, here the specification emerges, in collaboration with the stakeholders. This is why it need an ubiquitous language for non technical people and technical people to work together and talk to each other.

Unlike TDD, where you make technical tests that drive the design by failing and then passing, here the tests drive the specification, because they represent end user behaviors. For instance, they generally describe stories’ acceptance criteria.

Generally using pseudo human language such à Gherkin.

behavior-driven development (BDD) is an agile software development process that encourages collaboration among developers, QA, and non-technical or business participants in a software project

— https://en.wikipedia.org/wiki/Behavior-driven_development

encourages teams to use conversation and concrete examples to formalize a shared understanding of how the application should behave

— https://en.wikipedia.org/wiki/Behavior-driven_development

BDD is principally an idea about how software development should be managed by both business interests and technical insight, the practice of BDD does assume the use of specialized software tools to support the development process

— https://en.wikipedia.org/wiki/Behavior-driven_development

The tools serve to add automation to the ubiquitous language that is a central theme of BDD

— https://en.wikipedia.org/wiki/Behavior-driven_development

BDD is largely facilitated through the use of a simple domain-specific language (DSL) using natural-language constructs (e.g., English-like sentences) that can express the behaviour and the expected outcomes.

— https://en.wikipedia.org/wiki/Behavior-driven_development

Cucumber School - Give Me An Example

  • External reference:

Notes linking here