Test-driven development (TDD), Behavior Driven Development(BDD) , Gherkin Language

Test Driven Development

Test Driven Development (TDD) is a software development approach in which test cases are developed to specify and validate what the code will do. In simple terms, test cases for each functionality are created and tested first and if the test fails then the new code is written in order to pass the test and this makes code simple and bug-free.

Test-Driven Development starts with designing and developing tests for every small functionality of an application. TDD instructs developers to write new code only if an automated test has failed. This avoids duplication of code.

TDD Principles

TDD combines programming, unit testing, and refactoring, all of which leads to clean code, an easily-modified application, and an application that answers the expressed needs of the client, which remains the first priority.

TDD has three phases:

• RED. First, a unit test is written in failure. Not being able to compile is a failure.
• GREEN. The production code that can pass the unit test is supposed to be written as soon as possible, even if the code counts as a “bad solution”. However, if a clean and simple code is possible within the first few tries, then it should be applied immediately, too. The main objective here is to obtain the green bar for the unit tests.
• REFACTOR. Although this phase is often skipped, it is quite crucial because it eliminates code duplication and makes it possible to make changes in the architecture, presentation, and more. The refactoring involves both the unit test code and the production code.

The TDD cycle is short and is repeated until all unit tests that cover functionalities have been successfully completed:

Behavior Driven Development

Behavior Driven testing is an extension of TDD. Like in TDD, in BDD also we write tests first and then add application code. The major difference that we get to see here are

• Tests are written in plain descriptive English type grammar
• Tests are explained as behavior of application and are more user-focused
• Using examples to clarify requirements

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 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’.

Behavior Driven Development Tools

There are several open-source and paid tools available for BDD framework. Here are some of the common examples below.

1) Cucumber Studio
2) Cucumber
3) JBehave
4) SpecFlow
5) Jdave
6) Instinct
7) Specs

What is Gherkin Language?

Gherkin is a business readable language which helps you to describe business behavior without going into details of implementation. It is a domain specific language for defining tests in Cucumber format for specifications. It uses plain language to describe use cases and allows users to remove logic details from behavior tests.

This script serves two primary purposes:

• Documents user scenarios
• Writing an automated test (BDD)

Writing Gherkin Test:

There are some keywords used in Gherkin to define complete tests including precondition, 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

The feature is a description of what the application is supposed to do. Feature keyword is also used to group multiple scenarios together. 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.

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.

Syntax:

Given — a test step that defines the ‘context

Given I am on “/.”

2. When

‘When’ is used to describe an event and an action. This can be a person or user interacting with the system. It is 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.

Syntax:

When

A When — a test step that defines the ‘action’ performed

When I perform “Sign In.”

3. Then

“Then” keyword is used to describe an expected result or an outcome.The result 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.

Then

Then — test step that defines the ‘outcome.’

Then I should see “Welcome Michael.”

4. And, But

When we have multiple steps ,for example we have two 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.

A But — additional test step which defines the ‘action’ ‘outcome.’

But I should see “Welcome Michael”

And — additional test step that defines the ‘action’ performed

And I write “Email Address” with “Michael@gmail.com”

Given, When, Then, and, but are test steps. You can use them interchangeably. The interpreter doesn’t display any error. However, they will surely not make any ‘sense’ when read.

Background

The same ‘Given’ steps in all of the scenarios in the feature are being repeated then 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.We can only have 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.

Typical Gherkin steps look like:

Gherkin Scripts: connects the human concept of cause and effect to the software concept of input/process/output.

Gherkin Syntax:

Feature: Title of the Scenario

Given [Preconditions or Initial Context]

When [Event or Trigger]

Then [Expected output]

Gherkin Examples

Example 1:

Feature: Login functionality of social networking site Facebook

Given: I am a Facebook user

When: I enter username as username

And I enter the password as the password

Then I should be redirected to the home page of Facebook

The scenario mentioned above is of a feature called user login.

All the words written in bold are Gherkin keywords.

Gherkin will analyze each step written in the step definition file. Therefore, the steps are given in the feature file and the step definition file should match.

Example 2:

Scenario : Add product to the cart

Given the user is in the product page that he want to buy

When the user clicks “Add to cart”

Then the item should be added to the cart

Example 2

Scenario : Deleting items from the cart

Given the user have added some items in the cart

When the user clicks delete the item in the shopping cart

Then the item is deleted and cannot be seen in the cart again

Advantages of Gherkin

• Gherkin is simple enough for non-programmers to understand.
• Programmers can use it as a very solid base to start their tests.
• It makes User Stories easier to digest.
• Gherkin script can easily be understood by business executives and developers.

Disadvantages of Gherkin

• It requires a high level of business engagement and collaborations
• May not work well in all scenarios
• Poorly written tests can easily increase test-maintenance cost

** Source of Pictures: www.google.com

Originally published at https://www.numpyninja.com on May 8, 2021.