Behavior-Driven Development is an Agile software development process that promotes collaboration between developers, software testers (QA) and the non-technical, business side in a software development process.
Outcome of their meetings are structured scenarios which act as requirements for product owners, acceptance criteria for developers, description for stakeholders, test cases and automation scripts for testers.
Our focus in this blog will be on test cases and automation scripts for testers. However, if you would like to read more about BDD itself, you can check out my previous blog which explains the BDD processes more thoroughly.
Cucumber and Gherkin
Behavior-Driven Development is supported by a software tool called Cucumber. It is used to write acceptance tests for the software, and to run the tests in BDD style.
Source: miro.medium.com
Cucumber uses a plain language parser called Gherkin , which is of great importance to the Cucumber BDD approach. Thanks to Gherkin, we can write expected software behaviors specified in a logical and structured language that everyone on the project can understand — from developers to the customers.
Feature File is a starting point of the Cucumber test because it serves as an automation test script and the living documentation. Feature files can contain scenarios, scenario steps, scenario outline, tags and examples. All the feature files end with the “.feature” extension (Login.feature).
Example 1:
Feature: GoogleSearching
In order to find company information
As a user
I need to be able to search Google
Scenario:Google Searching
**Given** a web browser is at "Google" homepage
**When** the user enters "Bornfight" into the search bar
**Then** links related to "Bornfight" are shown on the result page
Scenario: Video search
**Given** Google search results for "Bornfight" are shown
**When** the user clicks on the "Videos" link at the top of the result page
**Then** videos related to "Bornfight" are shown on the result page
Feature gives information about a standalone unit or functionality of a project. It may also contain Description of the feature (In order to…As a user…I need to be able…).
Scenario represents a particular functionality of a feature which is under test. One feature file can contain more than one scenario, but one scenario can have only one behaviour. If you felt a need to use When and Then more than once in your scenario, it means that there are two behaviours and there is a space for two separate scenarios. Referring to the Example 1, this would be an incorrect way to write the scenario.
Example 2:
Scenario: Google Video search shows videos
**Given** a web browser is at "Google" homepage
**When** the user enters "Bornfight" into the search bar
**Then** links related to "Bornfight" are shown on the result page
**When** the user clicks on the "Videos" link at the top of the result page
**Then** videos related to "Bornfight" are shown on the result page
You probably noticed here that When and Then are repeated, and there are two different actions/behaviours meaning that you should write two different scenarios. By seeing the scenario, any of the stakeholders should be able to understand what is being tested. Scenario is always followed by scenario steps in the Given-When-Then format.
Given — Prediction — Context
When — Action — Event
Then — Outcomes — Result
This is a Gherkin format where the steps must be written strictly in this order and none of them should be repeated. If you want to add more than one line in each step, you can use And or But. Both of them are logically the same, except for the fact that But is used in a negative way.
Example 3:
**Given** a web browser is at "Google" homepage
**When** the user enters "Apple Inc." into the search bar
**And** the user search for images
**Then** the images related to "Apple Inc." should be shown
**But** the images related to fruit Apple should not be shown
Scenario outline , together with Examples , is used when you perform the same test with different data sets. In this example, we checked if all the team members are presented on the company’s web page.
Example 4:
Feature: CheckBornfightTeam
In order to check if Bornfight web is updated with the new team members
As a Bornfight web visitor I need to see new team member's name in the list
**Scenario Outline:** Check Bornfight Team
**Given** I am on page "/team"
**When** I look up for the team member
**Then** I should see "<name>" name
**Examples:**
| name |
| Kristijan Bujanović |
| Marko Kruljac |
| Josip Trbuščić |
| Ajdin Mustafić |
Tags
Scenarios and features can contain tags and they are marked with @. With tags, we can group scenarios and features in an order that we want to run them. For example, we can mark important scenarios with @important or scenarios for smoke testing with @smoke… Tags are very useful for arranging scenarios when you have 10–20 of them in one feature.
Steps definitions
Defining all the elements in the feature file doesn’t mean that the tests are ready to be executed. We have defined test scenarios, but the Cucumber doesn’t really know which piece of code should be executed for each line of the scenario. For that reason, we need a steps definition file, a glue between the scenario and the application. In the steps definition file, we have a mapping between each step of the scenario and the code of function to be executed.
In our examples, we use PHP with Codeception and Selenium to write tests and run them in the browser. Here you can see how each line in our scenario looks as a code.
Scenario: Google Searching
**Given** a web browser is at "Google" homepage
public function aWebBrowserIsAtHomepage($arg1)
{
$this->amOnPage('/');
}
**When** the user enters "Bornfight" into the search bar
public function theUserEntersIntoTheSearchBar($arg1)
{
$this->pressKey("//input[@name='q']", $arg1, \Facebook\WebDriver\WebDriverKeys::ENTER);
}
**Then** links related to "Bornfight" are shown on the result page
public function linksRelatedToAreShownOnTheResultPage($arg1)
{
$this->waitForText($arg1);
$this->see($arg1);
}
Conclusion
This is one basic example of how the scenario steps and steps definitions are connected. However, depending on the requirements of the test and the complexity of the tested feature, writing step definitions can get more complicated. While on the other hand, writing scenario steps should remain basic and easy to understand.
As you can see, the scenarios written in Gherkin are a documentation that’s structured and very easy to understand. A documentation which you can use to run acceptance tests. Also, they are easy to write and edit, therefore we can address them as living documentation. In short, writing feature scenarios in the BDD approach is of great value when it comes to testing, test coverage, documenting features, editing documentation and confirming that the feature works as it was intended to.
If you want to learn more about BDD, check out some of these articles:
Top comments (0)