Introduction to the methodology of Behavior Driven Development

BDD is based on the agile methodology called Test-driven development. The practice of BDD was started by Dan North in 2003 and was aimed at improving collaboration between developers, testers, managers and customers. It placed a strong emphasis on the behavior of a system, which should be understood equally by all involved parties. It can be accomplished by writing understandable stories, in which application’s behavior is described. Those stories consist of fixed components - Given, When and Then. BDD is used to learn as much as possible about expectations and needs of the client. In this method of approach to testing the most important aspect is that stakeholders have a significant impact on the software development process.

Key assumptions of BDD

As mentioned above, what counts above all in the BDD is a behavior of software, which has to be understood by all those involved in the development process. Created story or user stories are written in a natural language that is understood by all project managers, developers, analysts, testers and, of course, clients. Examples that are used illustrate the behavior of a software.

There are many ways to create such a story. Let's start with title and narrative. The title is intended to describe a story, it's best if it’s as short as possible and it it fits in a one line. The next part of the story is its narrative, which has to briefly describe a functionality of a software and its benefits - a role, function and benefit:

As a [role]
I want [feature]
So that [benefit]

 Here we have a basic user story:

As a [stakeholder or any user role]
I want [an action to be taken by user]
So that [a business value is provided]

How to create a User Story

Again, user stories are used to meet customer requirements for the system. They consist of three parts: the title, the narrative, and acceptance criteria. I described the first two components, so now it’s time to talk a bit more about the third one - the acceptance criteria that defines the moment at which our story is finished. It consists of 3 blocks:

1. Given (assuming) – defines the context and creates a section in which we set the initial assumptions. We also set the state of the system (which can be called the state of the world) for the purpose of testing. At this point, the initial conditions are described;
2. When – defines an event that allows us to describe the action that we want to test;
3. Then – specifies the result, in which we check whether the application is preserved as expected. It’s the place where expected results should be included, for example:
4. Given [some preconditions of scenario],
5. When (“I do” - some actions are taken),
7. Then (“I should see” - we should see an expected outcome)

Now it’s time for the final version of the scenario, which contains title, narrative and acceptance criteria:

• Feature: Search feature on a website In order to buy products
  Customers should be able to
  Find products using search feature

• Scenario: When a user searches for a product, it should be displayed Given User is on the main page of my shop   
  And user wants to spend 50$ on products in my shop
  When User searches for glasses
  Then user finds a product

BDD tools

The most common tools that you use to test the behavior of an application while using Behavior Driven Development (BDD) are currently: Cucumber, JBehave, Behat, SpecFlow and Jasmine.
A language that is used when creating scenarios in Cucumber or Behat is Gherkin. It's simple, easy to understand and is used to describe the behavior of an application. Gherkin is not only readable, but its code is used as a documentation of the project and is a substrate for test automation.

Benefits of introducing BDD

So, what are the benefit of introducing BDD techniques in your own company? First of all, it helps to focus on issues in software development that are really important for customers and have a business value. A whole team is involved in the project, what is certainly reflected in the improvement of communication within the company.

In conclusion, citing the Agile Manifesto, by using BDD we value more:

• people and interactions, not processes and tools,
• working software, not detailed documentation,
• cooperation with clients, not contract negotiations,
• reacting to changes, not realization of an established plan

Elements listed on the right are valuable, but not as important as the ones listed to the left.

Last but not least, another thing that's obviously very important is a quality product . When you are aware of all requirements, then you can provide as good of a product as possible. Customer satisfaction and high product ratings are priceless!