BDD: Automation Testing with Cucumber

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.

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:

• Automation Testing Using Cucumber Tool And Selenium – Selenium Tutorial #30
• Cucumber Feature File
• BEHAVIOR DRIVEN DEVELOPMENT
• Cucumber – Features