Understanding Behavior Driven Development (BDD):

What is BDD?

Definition:

Behavior Driven Development is the collaboration and conversation to discover essential requirements and identify uncertainty using rules and examples expressed in a common language to build a shared understanding to deliver software that matters.

In simple terms, Behavior Driven Development (BDD) is an agile software development practice that encourages collaboration between everyone involved in developing software: the triad; developers, testers, and business representatives such as product owners or business analysts. BDD often begins at the very beginning of the software development cycle after a user story is written.

Goal of BDD:

The goal of BDD is to create a shared understanding of how a software should behave and the outcome is to turn specifications into acceptance tests.

Phases of BDD:

Illustration phase/discovery Phase:

In this phase ,the triad: business, developers and testers create examples that describes the intended behavior that is going to be developed and ensure that everybody is talking about the same thing and everybody has same understanding about what they are going to build. The outcome of this phase is the artifacts.

Formulation phase:

In this phase, the artifacts created in the illustration phase are turned into a more formalized language, which is typically done using the Gherkin syntax also known as, Given-When-Then syntax.

Automation Phase:

In this phase, we use tools to create Automated Acceptance Tests, also known as the Executable Specifications, based on the specifications we created using Gherkin syntax. This forms the living documentation. Why they are called Living Documentation? Because these documents are executable documents which gives immediate feedback whether the system, we are building is meeting all the required specifications. This document gets updated whenever there is a change. Thus, specification is tightly tied with the software.

Validation Phase:

Even though, the software is tied with the specification and built, validation is necessary to make sure that we did the right thing.

How to implement BDD?

Even though, the entire process is called BDD, the implementation of the concept begins in the formulation phase. For this Gherkin is used as a language. The basic syntax for Gherkin is:

Feature: Some terse yet descriptive text of what is desired
  In order to realize a named business value
  As an explicit system actor
  I want to gain some beneficial outcome which furthers the goal
 
  Scenario: Some determinable business situation
    Given some precondition
      And some other precondition
     When some action by the actor
      And some other action
      And yet another action
     Then some testable outcome is achieved
      And something else we can check happens too
   Examples:

For a better understanding , consider an example case where we only allow authenticated users to login into a website, say ‘library’. In this scenario, the Gherkin syntax will be written as follows:

Feature: Test login portal
Scenario Outline: Valid user logged in
Given: Customer opens the login portal
When: user enters the username as “<user>” & password as “<password>”
Then: the customer should be able to view the form.
Examples:
|user1   |password1|
|user2 |password2|
|user3 |password3|

There are many additions possible which you can explore more in the tool used. Development teams can utilize these feature files and convert them into executable programs to test a particular feature. This Gherkin scripts are written inside BDD tools which allows testers and developers to continue working on implementation. This tools may vary depending on the language used for development. Some of the BDD tools used are:

Net and C#:

• SpecFlow

• xBehave.net

• LightBDD

• NSpec

• Concordion

Java:

• Cucumber-JVM

• JBehave

• Concordion

JavaScript:

• Cucumber.js

• Yadda

PHP:

• Behat

• Codeception

Python:

• Behave

• Lettuce

• Radish

Ruby:

• Cucumber

How BDD, ATDD and TDD differs?:

BDD and ATDD concepts are often misunderstood as same. ATDD and BDD are very close to each other but they have different outcomes.

In both ATDD and BDD, the collaboration of the triad, result in the artifact which is the representation of the behavior of the system. So, what is the difference? The difference is BDD emphasizes on creating the scenarios in the Given/When/Then format which becomes test later in the phase whereas ATDD focus on creating testable scenarios based on the acceptance criteria. In ATDD , acceptance tests are written before writing code.

Gherkin is used to represent both ATDD and BDD. And understand that Gherkin is not BDD. Gherkin is the simple language used to formulate BDD.

TDD involves developer/tester in creating tests that describe the responsibilities for the implementation of the scenarios. Tests are passed in a very short period.

As an observation, BDD can help improve the quality of the product when used efficiently. And to the core point, the most important principle always to be followed is shared understanding.

Hope this is helpful. Thanks for reading!