DETAILED READ SECTION

Learn Behavioral Driven Development


What is BDD?


Behavioral Driven Development (BDD) is a software development approach that has evolved from TDD (Test Driven Development). It differs by being written in a shared language, which improves communication between tech and non-tech teams and stakeholders. In both development approaches, tests are written ahead of the code, but in BDD, tests are more user-focused and based on the system’s behavior.


Choosing BDD


TDD works satisfactorily, as long as the business owner is familiar with the unit test framework being used and their technical skills are strong enough, which is not always the case. In these circumstances, BDD has the advantage because the test cases can be written in a common language used by the stakeholders such as, for example, English. This access to clearer, low-jargon communication is probably the biggest advantage to using BDD, making it possible for collaboration between the technical and non-technical teams to run with improved efficiency.


Characteristics of BDD


As described above, the advantage to BDD test cases being written in a common language is that details of how the application behaves can be easily understood by all. For example, test cases can be written using real-time examples of the actual requirements, to explain the behavior of the system.


Essentials to have in place before implementing BDD

  • Requirements should be converted into user stories that can define concrete examples.

  • Each example should be a valid user scenario, rather than a mere test case.

  • An understanding of the ‘role-feature-reason’ matrix and the ‘given-when-then’ formula.

  • An awareness of the need to write ‘the specification of the behavior of a class’ rather than ‘the unit test of a class’.


BDD Frameworks


Cucumber

Cucumber is a test framework that supports BDD. In Cucumber, the BDD specifications are written in plain, simple English which is defined by the Gherkin language. In other words, Gherkin is a language that Cucumber understands. Gherkin presents the behavior of the application used, from which Cucumber can generate the acceptance test cases. Cucumber is a framework developed by Ruby that can work across different technologies.


JBehave

Another popular framework for BDD.


Specflow

Specflow evolved from the Cucumber framework using Ruby on Rails, and is used mainly for .Net projects. SpecFlow also uses the Gherkin language.


BDD Terminology:


1) Feature Files or Story Files:

Feature / Story files are the essential part of BDD which is used to write test automation steps or acceptance tests. This can be used as the live document. The steps are the application specification. All the feature files end with .feature extension. All stories file end with .story extension.


Stories file created in JBehave Framework and Feature files created in Cucumber Framework.


2) Scenario:

Basically, a scenario represents a particular functionality which is under test. By seeing the scenario user should be able to understand the intent behind the scenario and what the test is all about. Each scenario should follow given, when and then format. This language is called as “gherkin”.


Given: As mentioned above, given specifies the pre-conditions. It is basically a known state.

When: This is used when some action is to be performed. As in above example, we have seen when the user tries to log in using username and password, it becomes an action.

Then: The expected outcome or result should be placed here. For Instance: verify the login is successful, successful page navigation.

Background: Whenever any step is required to perform in each scenario then those steps need to be placed in Background. For Instance: If a user needs to clear database before each scenario then those steps can be put in a background.

And: And is used to combine two or more same type of action.


Sample feature file:

Feature: Login Functionality Feature

In order to ensure Login Functionality works,

I want to run the cucumber test to verify it is working


Scenario: Login Functionality

Given user navigates to nextgenerationautomation.com

When user logs in using Username as “USER” and Password “PASSWORD”

Then login should be successful


Sample Story File:

Search functionality


Narrative:

In order to show the advance cart functionality

As a user

I want to search for an item in a sub category


Scenario: Advanced Search for a hat

Given I am searching on Etsy.com

When I specify the Vintage sub category

And I search for hat

Then there are search results


3) Scenario Outline


Scenario outlines are used when the same test has to be performed with different data set. Let’s take the same example. We have to test login functionality with multiple different sets of username and password.


Sample Login.feature file:


Feature: Login Functionality Feature


In order to ensure Login Functionality works,

I want to run the cucumber test to verify it is working


Scenario Outline: Login Functionality


Given user navigates to nextgenerationautomation.com

When user logs in using Username as <username> and Password <password>

Then login should be successful


Examples:

|username |password |

|Ankur |password1 |

|Peter |password2 |

|Alisha |password3 |


Note:

As shown in above example column names are passed as a parameter to When statement.

In place of Scenario, you have to use Scenario Outline.

Examples are used to pass different arguments in the tabular format. Vertical pipes are used to separate two different columns. An example can contain many different columns.


Note:

  • As shown in above example column names are passed as a parameter to When statement.

  • In place of Scenario, you have to use Scenario Outline.

  • Examples are used to pass different arguments in the tabular format. Vertical pipes are used to separate two different columns. An example can contain many different columns.

4) Tags:


Cucumber by default runs all scenarios in all the feature files. In real time projects, there could be hundreds of feature file which are not required to run at all times.


For instance: Feature files related to smoke test need not run all the time. So if you mention a tag as @SmokeTest in each feature file which is related to smoke test and runs cucumber test with @SmokeTest tag. Cucumber will run only those feature files specific to given tags. You can specify multiple tags in one feature file


Example of use of single tags:

@SmokeTest

Feature: Login Functionality Feature


In order to ensure Login Functionality works,

I want to run the cucumber test to verify it is working


Scenario Outline: Login Functionality


Given user navigates to nextgenerationautomation.com

When user logs in using Username as <username> and Password <password>

Then login should be successful


Examples:

|username |password |

|Ankur |password1 |

|Peter |password2 |

|Alisha |password3 |


Some benefits to using BDD

If you plan to implement BDD, here are a few points that will benefit the software team.

  • You are no longer defining ‘test’, but are defining ‘behavior’.

  • Better communication between developers, testers and product owners.

  • Because BDD is explained using simple language, the learning curve will be much shorter.

  • Being non-technical in nature, it can reach a wider audience.

  • The behavioral approach defines acceptance criteria prior to development.


Lets look at How TDD compares to BDD?


In TDD approach, developer assume the behavior of software application and then write unit tests

In BDD approach, Business Analyst or Client knows the requirement of his product and generates scenarios based on real life usage of his product


TDD is inside-out, push based where unit tests drives the software development

BDD is outside-in, pull based where behavior tests drives the software development





Summary

BDD lets us develop, test and think about the code from the view of the business owner. You need to have the mindset to implement ‘real time examples’ rather than implementing just ‘functionalities’







#DevelopmentInProgress