Behavior Driven Software Development can be really helpful in developing good and popular software, that will be repeatedly run through thorough specifications and be really easy to use.

No matter whether you wish to improve software code or significantly increase automation usage on the basis of Cucumber framework — only one software development language is in the center of the entire BDD and it’s Gherkin.

Gherkin may first seem very easy. You just need to create a number of test cases that will describe the desired behavior of software that is being tested.

But sometimes it’s very hard for testers to write tests using this language.

Junior QA engineers sometimes suffer from so-called “writing stupor” or try to create scripts that can’t be automated.

Sometimes public conflicts make people understand (interpret) test steps in different ways.

Also, sometimes testers add too many details to test steps and this makes such scripts too complex to understand. Public annoyance of Gherkin can lead to a bad reputation for BDD.

It may be not very easy to write qualitative tests with Gherkin but it’s not impossible.

Further, we’ll talk about two main rules that help to create completely readable, scalable, and easy-to-automate tests.

Rule 1: Gherkin’s golden rule

A so-called “Gherkin’s golden rule” is very simple: [highlight dark=”no”]try to treat users in the way you wish they treat you.[/highlight]

This means that you should make feature files completely clear to everyone.

Only qualitative Gherkin can improve the overall team’s collaboration by rapidly explaining the behavior that you should develop as a tester. When it’s hard to develop Gherkin, it will be impossible to elaborate the desired behavior.

Lets’ imagine that the X project team is developing a website that sells jackets. Let’s analyze the following script.

Script: purchasing a jacket.

• Given a user wants to buy a jacket;
• When he/she buys the jacket;
• Then the user receives the jacket.

It’s in some way the ultra-declarative test script since it provides little useful information on the desired behavior.

It can be described as too vague. What jacket? How can we order it? How can we check the order’s status? All this is a part of a big user story but not a technical specification.

The user script also has a lack of accountability — it tells completely nothing about the conditions for future success.

Usually, production owners mostly use ultra-declarative scripts since they are the only ones who know little about an automation process.

Now we can analyze another clear example of an extreme test script.

Test script: buy boots with the help of a program.

• Given a user’s login is user0011;
• And the user’s password is password0011;
• When the user visits a website;
• And enters his/her password and login;
• And clicks on the validation button;
• And waits for 5 seconds;
• Then a boot catalog is displayed on the website;
• And he/she finds a search box;
• And he/she enters the name of the required model;
• And he/she clicks on the Search.

It’s an example of a typical ultra-imperative test script since it’s very detailed.

All test steps show low-level tests — clicking on buttons, working with forms, and so on.

But they completely overload the user with text that simply hides but doesn’t explain the importance of the test script.

These steps may be automated but common interaction is completely complex.

If you were present in such a team, would you like to work with such scripts? Of course, not since none of them can build desirable user behavior.

Rule 2: the main rule of BDD

The main rule of BDD is in some way one-to-one rule: [highlight dark=”no”]only one script should cover one function, one independent behavior.[/highlight]

If you are focused only on one behavior at one time, it’s very profitable:

• Collaboration: the higher is concentration, the less confusion you will get ;
• Automation: if one test fails, we can say for sure what is the reason;
• Efficiency: easy work accelerates a working process;
• Tracking: one behavior — one example — one result;
• Clarity: project teams can’t change or avoid desired behavior.

It’s great that a script can cover more than one behavior and it’s easy to understand.

For example, there is the following result.

Script: searching for products.

• Given a user visits a web store’s home page ;
• When he/she enters the X product in a search box;
• Then he/she should see the Results age;
• When the user searches for products that contain images;
• Then he/she should see the images only for the X products.

This script shows two examples of behavior at once: searching for products and searching for products that contain images. Every “when-then” pair describes the unique behavior of a system.

If a script contains more than one example of such a pair, it shows several behavior patterns at once by default.

The above-mentioned rules — it’s a practical guide to creating qualitative Gherkin.

Practice, search for unique constructions to create useful scripts and you will never stop using Gherkin.