Behavioral Driven Development (BDD) all started from a simple blog post by Dan North in 2006. I”ll let you read the post for the detailed description, but the tl;dr is that he was looking for a better way to teach and communicate the practices of Test Driven Development (TDD). So, BDD was formed to bridge the gap between what should be tested and how to better communicate requirement between the business and developers.
The premise of BDD is to simplify the communication between business owners and developers by using examples to explain acceptance criteria. The examples provide clarification about specific criteria that the business owner expects to see from a feature, and in BDD they also provide the “Acceptance Criteria” for the story. In it’s simplest form I usually break the BDD process into the following 3 steps.
- 3 Amigo Story Huddle discuss example of what should be built
- Business Analyst
- Quality Assurance Engineer
- Define each example (aka scenario) using the Gherkin Syntax
GIVEN I navigate to the insurance policy 1234 WHEN the policy owner information is shown THEN I am able to choose a my coverage level
- Automation of the the scenarios
There are many BDD tools available to parse Gherkin scenarios and create test cases out of them. For example my development team is using SpecFlow because our Acceptance Tests are written in .Net. SpecFlow simply parses the Gherkin to generates NUnit tests which can then be ran via the typical NUnit console runner. The beauty of using these tools is that it allows non technical folks to create the acceptance criteria using business (not technical) language.