Software Testing: BDD Best Practices

Best BDD practices are undoubtedly one of the elements of conducting effective software tests. Initially, this approach was aimed at supporting software development processes on a relatively small scale. Currently, it works very well even in more advanced projects. What is BDD? It is a software development methodology that is driven by behavior (BDD – Behavior-driven development). Interested in details? From the text, you will learn:

• what exactly is the BDD approach?
• how to schematically describe the assumptions of BDD?
• what to look for when creating test scenarios?
• what elements should be included in the feature? What’s in the scenario? What is the steps part?

Best BDD Practices- what is it all about?

In practice, the BDD (Behavior-Driven Development) approach enhances software engineering practices by shifting the focus toward delivering solutions of higher quality. By ensuring that all stakeholders (clients, business analysts, testers, and developers) involved in the creative process operate within a unified conceptual framework, work proceeds efficiently. BDD doesn’t solely concentrate on implementing the system but primarily emphasizes its desired behavior. In other words, we examine how the system should behave based on specified conditions and user actions. In BDD, we begin by creating user stories to establish requirements. User stories are scenarios described in a manner that is understandable to all parties involved. To facilitate this, we employ the Gherkin language, which stems from the BDD approach.

Schematically, the principles of BDD using the Gherkin language can be described as follows:

GIVEN – preconditions/necessary conditions that must be met to start the scenario

AND – may appear as a continuation of the Given

WHEN – an action that is supposed to cause some behavior in the application

AND – can occur as a continuation of When

THEN – the expected result of the action performer

The above steps are enough for us to create dynamically changing requirements documentation during the development of software that is more user-oriented.

Good BDD practices

It is worth keeping the following sequence of actions: feature -> scenario -> steps

What are these terms and what else should be kept in mind?

• Feature – describe the functionality
• Scenario – description of what you are verifying in the scenario – what is going to happen
• Steps – write reusable steps, user story (given, and, when, then)
• Background – assumption, steps that are common to different scenarios
• Scenario Outline – created for a scenario with additionally various test cases
• Examples – test cases

Best BDD practices – what to remember when creating a script?

It is best to explain the whole process based on the scheme indicated above: feature -> scenario -> steps

Feature:

• description of functionality – what should happen after completing the scenario

Scenario:

• each scenario should be possible to execute independently
• the behavior-oriented scenario title should answer the question “What do I want to test?”
• We use Scenario Outline when we want to save different cases for 1 scenario. To save the scenario correctly, use “< >” for the “place” that will be parameterized. Using the notation consistent with the photo below.

Scheme of correct writing:

Feature: Description of functionality

Scenario Outline: title (description of what will be tested and verified)

Steps: (reusable, imperative, or declarative approach)

Examples: the variable stored in < >

Test case examples for one user:

• the correct test case writing scenario for the same user:

• wrong scenario of writing test cases for the same user:

• Background is used to record steps that are repeated in scenarios for the same functionality

Scheme of correct writing:

Feature: title (description of functionality)

Background: steps

Scenario: title (description of what will be tested, what we verify)

Steps: (reusable, imperative, and declarative approach)

Example:

• Scenarios before applying Background:

• Scenarios after applying Background:

Steps:

• steps should be independent, and maximally descriptive (for example: instead of “I approve” – “I approve the payment on the main page”). Don’t create identical steps in different scenarios unless they have the same purpose and impact
• When and Then are used once in a scenario. When and Then describes one behavior in onescenario. If we have more than one behavior in a scenario, they should be separated into two separate scenarios, remembering that Given – configures the beginning of the scenario – include the initial state here -> the second behavior requires the execution of the first. There are, of course, cases where we use double When – Then, but we try to limit writing in this way because it is not “consistent” with good BDD practice.
• when writing steps, we use the 1st or 3rd person singular form. Choose one option and use it consistently. It is a bad practice to use both personal forms alternately – the script is unclear and incomprehensible
• we save the test data in Examples, as in the example below:

We write steps for reuse. A hardcoded step to search for a specific phrase is not reusable, but a parameterized step to search for any phrase is. Parameterization – the best practice is to write parameterized values in double quotes. This makes the parameters easy to identify.

Example:

Imperative and Declarative Approach – Differences

Imperative steps focus on how to take action. Therefore, they often need multiple steps to fully achieve the intended behavior. Moreover, the intended behavior is not always as documented as with declarative steps.

Declarative steps specify what action should be performed without providing all the information on how it will happen. They are guided by behavior because they express action at a higher level. When trying to reduce the number of steps, ask yourself, can your steps be written more declaratively?

An example of testing the same functionality, written using two different approaches:

• in an imperative way (step by step what is going to happen)

Given: I opened the login page

When: I enter my login in the first text box

And: I enter my password in the second text box

And: I click the Login button

Then: I see a personalized page

• in a declarative way (you declare the desired results but not step by step):

Given: I opened the login page

When: I’m logging in with the correct details

Then: I see a personalized page

Summary

The use of best BDD practices in creating test scenarios not only facilitates operations but also translates into ensuring the quality of the designed system/application in an extremely effective way. At Opsenio, we know perfectly well how important testing is in project activities. Want to know more details? Feel free to contact us.