Mastering given-when-then

Behavior-driven development (BDD) practices can help your teams build better software by specifying the product’s behaviors with plain-language examples. And whether you're seeking better collaboration through "three amigos"* meetings or aiming to automate better using a framework such as Cucumber, one language rests at the center of the BDD movement: Gherkin. In this article, we will try to understand BDD’s essence and provide a good base for mastering Gherkin.

Behavior-driven development (BDD) can be described as the intersection between domain-driven design (DDD) and test-driven development (TDD). It simply aims to produce high quality and understandable code.

BDD consists of two parts. The first one is the “process” that determines how the software should behave. The second part is to “assure” that the software behaves as desired with the written automation codes.

BDD basically consists of cycles of a set of steps to follow:

• Identify business feature.
• Identify scenarios under the selected feature.
• Define steps for each scenario.
• Run feature and fail.
• Write code to make steps pass.
• Refactor code, create reusable automation library.
• Run feature and pass.
• Generate test reports.

Now that we have went through the basics of BDD, we can proceed to its contributions to teams and quality.

BDD strongly encourages the use of agile methodologies during the development and testing.

To achieve collaboration and high-quality products -especially in- remote environments, facilitation is necessary. BDD is very good way for teams to collaborate in understanding, documenting and verifying business requirements. Because BDD brings customers, end-users, BAs, QAs, and SMEs of the software product into one table for effective sharing of knowledge in a structured and comprehensible way.

Ambiguous, missing or unclear requirements not only lead to production issues, change requests and rework, but they also reduce quality and eventually ruin team’s reputation and motivation. Using BDD will reduce the probability of these issues by facilitating collaboration around clearly defined requirements and test steps.

Today, the Gherkin syntax is commonly used for describing functions and features. Let’s now dive into Gherkin’s details and see practical examples.

Gherkin is a form of plaintext format that allows you to explain in detail how the software will work. You can use these “phrases” when you build the framework of your automated tests.

Basically, Gherkin syntax, commonly known as the ‘Given-When-Then’ formula contains these keywords as shown below.

FEATURE: Subject heading.

BACKGROUND: Describes the situation before starting the scenario. It is not mandatory to use this.

SCENARIO: Where we start telling the story.

GIVEN: It is the first step of a test. It is the step where the prerequisites performed when starting the test are realized.

AND: Refers to intermediate actions.

BUT: Using for negative situations. It is not mandatory to use this.

WHEN: Describes the action taken by the user during testing.

THEN: This is the verification step: It refers the actual / expected result of the action taken.

A similarity can be drawn between Gherkin and literature. If we evaluate literary works in three areas:

• Style is good use of language. When writing a scenario, we should focus on stakeholders and think flow and result oriented.
• Composition section shows how to write scenarios easier with the Given-when-then template. It is about clarity and consistency of thought.
• Story section is needed to generate new ideas and every story has a hero.

Here are some practical tips that will help us to write readable, automatable, scalable Gherkin.

• We must write meaningful scenarios to connect with readers.
• Each gherkin scenario gives a brief description of the product.
• Write feature files so that everyone can intuitively understand them: clarifying behaviors is the key.
• One scenario should cover exactly one single, independent behavior. By doing this the scenario becomes more efficient and traceable, especially at the automation phase.
• Don’t include unnecessary examples. Testing “all the things” might sound tempting, but that wastes precious time. Instead, test the most important things, and avoid testing duplicate things.
• Using a good grammar also has huge importance when creating readable and expressing scenarios.
• Using tags for each scenario help for reporting statistic, tracking the approval rating of the scenario, and to quickly find any test results.

To summarize, we can review the items below to write good scripts using gherkins;

• We should avoid using inverted sentences,
• We must understand what the targeted outcome is in customer requirements.
• We must determine the right ways to achieve the goals,
• We must identify the actors,
• We must use appropriate data for the scenario,
• We should avoid using long and complex sentences,
• We should only use one action with the keyword "when",
• We must create scenarios for end users,
• We should stay away from interface dependency,
• The scenario should be understandable when read by all stakeholders.