Behavior Driven Development(BDD)And Implementation of Gherkin in BDD Behavior-driven development

Behavior-driven development is a popular agile methodology that can achieve good results. Behavior-driven development was invented well over a decade ago. Back then, a lot of teams were starting to adopt test-driven development.

Behavior-driven development started life as an NLP exercise to stem the abuse of the word “test” in “test-driven development”.

How is BDD different from TDD (Test-Driven Development)?

BDD is an evolution of TDD. In TDD, developers

(1) write unit tests and watch them fail.

(2) develop the feature to make the tests pass.

(3) refactor the code to make it stronger.

(4) repeat the cycle.

Test Driven Development Diagram

In BDD, teams do this same loop with feature tests (a.k.a “acceptance” or “black-box” tests) as well as unit tests. Furthermore, BDD adds shift left practices like Example Mapping and Specification by Example so that teams know what they are doing and focus on developing the right things.

Unlike TDD BDD :

⦁ Describes how the end user uses the software.

⦁ Fosters collaboration and communication.

⦁ Emphasizes on examples of behavior of the System.

⦁ Aims at the executable specifications derived from the examples.

BDD focuses on defining requirements based on the desired behavior of your software. These requirements can then be converted into code. Finally, you can use the same requirements to check for the correct behavior of your program.

BDD Process:

Prerequisites for implementing BDD:

Below are the prerequisites for implementing BDD:

1. All requirements should be created as a story and each user story should be very well defined with concrete examples.

2. Every example used in a user story must be a valid scenario explaining the user’s viewpoint and not only just a mere test case.

3. Sound understanding of BDD framework/process and the tool to be used.

4. Hands on with one of the programming languages (like JAVA (preferred), Python, Ruby, C#) that will be needed for automation of a test case in the backend.

Pros of using BDD:

Here are some of the key advantages of implementing BDD:

1. In BDD, you are not defining ‘test’, but defining the ‘behavior’ of the system in plain language to directly trace the business objectives which also helps in involving non-technical team members for reviews.

2. Improves communication among the team members like developers, testers, product owners and other stakeholders.

3. Having clear behavior visibility results in quality code which reduces the cost of maintenance and eliminates the risk.

4. Since BDD front-end is non-technical in nature and uses natural language to explain the behavior it helps in ensuring correctness of implementation from an early stage.

5. Acceptance criteria are already converted to user stories/test scenarios before the actual development in Behavioral Driven approach. Thus, automation testers can start with testing processes even before the product is ready for testing.

Cons of using BDD:

Here are some Cons of using BDD

1. BDD is not compatible with the waterfall approach.

2. BDD is ineffective without a proper definition of business requirements i.e with poorly written user stories .

3. tester should have sufficient technical and programming competency.

Behavior Driven Development Tools:

⦁ Cucumber

⦁ Spec Flow

⦁ Behave

⦁ JBehave

⦁ Lettuce

⦁ Concordion

⦁ Behat

⦁ Kahlan

⦁ DaSpec

⦁ Jasmine

⦁ Squish GUI Tester

⦁ Spock

⦁ Yadda

BDD Tool Selection :

BDD framework can be implemented using any one of the above mentioned tools based on the below factors :

⦁ The programming language being used in the source code of the product/project.

⦁ Nature of the Project.

⦁ Team competency, team discussions and other software requirements.

⦁ Approved budget in case of choosing a licensed tool.

However, among all of the above BDD tools, Cucumber is the most common and widely used tool. For writing specifications or business behavior in the frontend for BDD Frameworks, Gherkin is the most widely used language.

Gherkin:

Gherkin is a domain-specific language that enables the definition of business behavior without the need for implementation. Gherkin uses plain English language to define the test, which makes it easy for technical and non-technical team members to understand the test or behavior of the software.

Writing Gherkin Test:

There are some keywords used in Gherkin to define complete tests including pre-condition, test description, expected outcome etc. Here are some of the common keywords used in gherkin language:

1. Feature.

2. Scenario outline.

3. Given, When, Then, And, (Steps)

4. Background.

5. Scenario

6. Rule

7. Example

Each keyword has its own meaning used in writing a great Gherkin test. Those Keywords are explained below to have an understanding of each one of them.

Feature:

Each Gherkin file starts with a keyword Feature, followed by a definition of the logical test functionality to be tested on that feature file. In other words, the feature is a description of what the application is supposed to do. Feature keyword is also used to group multiple scenarios together. This isn’t only for testing purposes, but it also allows you to add documentation on requirements and business rules. Feature keyword is found at the start of a feature file.

Descriptions:

When required, free-form descriptions could be written underneath the given keywords, as long as all the lines are being written without any keyword.

Rule:

The purpose of the rule keyword is to represent one business rule that needs to be incorporated. This keyword provides additional context for a feature. These “rules” can have one or more scenarios that can belong to the business rule and may have a background section as well.

Gherkin Steps:

There are some gherkin steps specific keywords that are used in the Gherkin test. These are:

1. Given

2. When

3. Then

4. And

5. But

Now, let’s understand the use for each one of them below:

1. Given:

Given step is used to describe the initial information of the system. Usually, it is used to describe the prerequisites before a test case execution can start. When cucumber runs a Given step, it configures the system to be in an already defined state, such as object configuration or adding required data to a test database. The objective of Given step is to have the system in a known state before the user starts interacting with the When steps.Given steps are the preconditions if you are creating the use cases. It is also valid and okay to have several Given steps if required.

Few examples:

⦁ Mike and Jack have started the game

⦁ User is logged in

⦁ User has a balance of $40

2. When

Step written under When a keyword is used to describe an event and an action. This can be a person or user interacting with the software/system. Also, it could be an event triggered by another or an external system. It’s highly recommended that you have a single When step for one Scenario. If multiple when are needed, then it is advised to split that kind of scenario into multiple scenarios.

Examples:

⦁ Click login button

⦁ Invite a connection

⦁ Withdraw money

⦁ Declare a nominee

3.Then

Step written under ‘Then’ keyword is used to describe an expected result or an outcome. The step definition of a Then step uses an assertion to match the actual outcome (Actual outcome of the When step) to the expected outcome about what the system is supposed to do. The outcome of this step should be an observable output that is something like a report, message or user interface and not an internal behavior of the system like a record inside a database.

Examples:

⦁ See that the login was successful

⦁ The nominee is declared or added

⦁ Connection is invited

4. And, But

When we have multiple steps for the one type of step like for eg. 2 conditions that should be valid as a prerequisite then after ‘Given’ the two steps can be separated by an ‘And’. Similarly, for ‘But’. These can be used with ‘Given’,’ When’ or ‘Then’ as needed. Using these keywords helps in keeping the documentation more organized and increases readability by making it more structured.

Background

Sometimes you may find that you are repeating the same Given steps in all of the scenarios in the feature. Since they are repeated in each scenario, this is a sign that those steps are not essential to describe the scenarios. They are just the event details. We have an option to move such Given steps to the background by grouping them all under a Background section.

A Background enables you to add even more context to the scenarios in the feature. Background can also contain one or multiple Given steps.

A Background is executed before every scenario and after any Before hooks. We have to put the Background before the first Scenario in the feature file.

There can only be a single set of Background steps for one feature. If you want different Background steps for each scenario, you need to split them into different feature files.

Scenario Outline

The keyword Scenario Outline is used to execute the same scenario multiple times with different sets of values.

For eg, without scenario outline, passing multiple values to the same scenario as different cases increase the time and effort required in test case creation and execution, as can also be seen below:

1. Scenario: eat 6 out of 15

Given there are a total of 15 bananas

When I eat 6 Bananas

Then I will have 9 bananas

2. Scenario: eat 8 out of 20

Given there are a total of 20 bananas

When I eat 8 bananas

Then I will have 12 bananas

Above kind of scenarios can be described more concisely through Scenario Outline with the use of <> tags. For example:

Scenario Outline: Eating Bananas

Given there are <Total> Bananas

When I eat <eaten> Bananas

Then I should have <leftover> Bananas

Examples:

| Total | eaten | leftover |

| 15 | 6 | 9 |

| 20 | 8 | 12 |

In a BDD framework, there is a frontend file that uses Gherkin syntax and there is a backend file that is implemented using a programming language. In Cucumber, The frontend file is called a feature, and the backend file is called step definition.

In the step definition file, implementation is done corresponding to all the outlined steps in the feature file and the mapping is ensured. Read more about step definitions here.

During execution, before trying to match a step against the respective step definition, Cucumber would replace the parameters with values from the table.

Overall Feature File Example:

Eventually, we can say a feature file is the core specification or behavior of the system against the step definition. Below is a simple example to see how the overall feature file looks:

Benefits of Using Gherkin:

There are many advantages of using the Gherkin language to write and define the behavior in your BDD framework. Some of the major ones are mentioned below:

1. Gherkin is simple

2. Increases code reusability

3. Focuses on project requirements

Disadvantages of Using Gherkin:

Every tool and software has some limitations and disadvantages and Gherkin is no different about it. Here are some of the cons of using Gherkin:

1. Not for all projects

2. Potential Expense

3. It requires a lot of engagement

Conclusion:

Thus, BDD has been bridging the gap between developers and business for more than a decade now and has been quite successful in making the implementation as close to the behavior as possible.

By

Krishnaveni .L