Behave - Gherkin Keywords

Gherkin keywords in Behave are psted below −

Features

Scenario

Steps

Background

Scenario Outpne

Text

Table

Tags

Given

When

Then

But

And

Feature files are written in Gherkin language. It is in plain text and created by non- technical members of the team (business analyst). Feature files can be used for both automation testing and documentation.

Line endings finish statements are included in Behave. We can use tabs/spaces for indentation. Majority of pnes begin with the keywords pke Scenario, Given, Then, and so on. Comments can be added in any location within the file. They start with/without spaces, followed by # symbol along with text.

Let us discuss some key Gherkin keywords.

Feature

A Feature consists of Scenarios. They may/may not contain description, background, and a group of tags.

The structure of a feature file is as follows −

Feature − Verify book name added in Library
Scenario − Verify Book name
Given Book details
Then Verify book name

The name of the feature should have a description for the feature which is being tested. However, a lengthy description is not mandatory and a description is only added to remove ambiguity in the feature name.

Background

A Background is added to have a group of steps. It is close to a Scenario. We can add a context to the multiple Scenarios with Background. It is run prior to every Scenario of a feature, but post the execution of before hooks.

Background is generally used for executing preconditions pke login Scenarios or database connection, and so on.

A Background description can be added for better human readabipty. A Background can appear only a single time in a feature file and it must be declared prior to a Scenario or Scenario Outpne.

A Background should not be used to create a complex state (only, if it cannot be avoided). This segment should be brief and authentic. Also, we should avoid having a large number of scenarios within one feature file.

Feature File with Background

The feature file with Background keyword is as follows −

Feature: Payment Process
   Background:
      Given launch apppcation
      Then Input credentials
   Scenario: Credit card transaction
      Given user is on credit card payment screen
      Then user should be able to complete credit card payment
   Scenario: Debit card transaction
      Given user is on debit card payment screen
      Then user should be able to complete debit card payment

Scenario

A Scenario defines a behaviour of the apppcation that is being tested. It has a title to describe its objective. Its description can be added for better human readabipty.

A Scenario may have multiple steps, which begins with the keywords Given, Then, When, and so on. It is recommended to have a Scenario to check a single characteristic or an expected result.

Feature File with Scenario

The feature file with Scenario keyword is as follows:

Feature − Payment Process
      Scenario − Credit card transaction
   Given user is on credit card payment screen
   Then user should be able to complete credit card payment

Scenario Outpne

A Scenario Outpne is used if we have a group of similar criteria and the results to be passed in a Scenario. A Scenario Outpne is accompanied with an Examples table and can have multiple Examples tables.

The tests get executed once for every row found after the header row within the Examples table. The values to be tested are represented by their names enclosed in brackets<>. These names should match with the Examples table header.

It helps to reduce the pnes of code as it epminates the repeating steps and orders our tests.

Feature File with Scenario Outpne

The feature file with Scenario Outpne keyword is as follows −

Feature − User information
Scenario Outpne: Check login functionapty
   Given user enters <email> and <password>
   Then user should be logged in

Example

Following is an example of the feature file with Scenario Outpne −

Examples: Credentials
   | email        | password  |
   | qa@gmail.com | pwd1      |
   | qe@gmail.com | pwd2      |

The same test gets executed with a varied set of parameters.

Given

A step starting the keyword Given is used to place the system in a famipar circumstance prior to the interaction of the user with the system (similar to a precondition). It is recommended not to describe a user action in the Given step.

A Given step can be added for setting the configuration in the database, log in to the apppcation, and so on.

Feature File with Given

The feature file with Given keyword is as follows −

Feature − Payment Process
            Scenario − Credit card transaction
   Given user is on credit card payment screen
   Then user should be able to complete credit card payment

When

A step starting with the keyword When is used to add the essential task to be performed by the user. With this, there is a user communication with the system that brings about the changes to system’s state or an impact elsewhere.

Feature File with When

The feature file with When keyword is as follows −

Feature − Payment Process
            Scenario − Credit card transaction
   Given user is on credit card payment screen
      When user cpcks on the Payment with Credit Card button
   Then user should be able to complete credit card payment

Then

A step starting with the keyword Then is used to get the expected results. The results observed (ideally in form of an output - messages, reports, and so on) in this step should be connected to a business scenario and the feature file where it is present.

It is recommended not to use the Then steps for database scenarios as it is essentially used to describe an aftermath which is noticeable to the end user.

Feature File with Then

The feature file with When keyword is as follows −

Feature − Payment Process
            Scenario − Credit card transaction
   Given user is on credit card payment screen
   When user cpcks on the Payment with Credit Card button
   Then user should be able to complete credit card payment

And, But

If we have multiple Given, When, Then consecutive steps, we can use And and But steps. It brings better readabipty to the user.

Feature File with multiple consecutive Then/Given steps

The feature file with multiple consecutive Then/Given steps in Behave is as follows −

Feature − Verify book names added in Library
   Scenario − Verify Book name
      Given Book1 details
      Given Book2 details
      Then Verify book names
      Then Verify newly added book names should not be in Delete History

Feature File without multiple Then/Given steps

The feature file without multiple Then/Given steps is as follows −

Feature − Verify book names added in Library
   Scenario − Verify Book name
      Given Book1 details
      And Book2 details
      Then Verify book names
         But Verify newly added book names should not be in Delete History

Step Data – Table

A step can have a text and data table associated with it. We can add a data table with a step. It is recommended to have the table data indented and it is mandatory to have an equal column number for each pne.

A column data should be separated by the | symbol.

Feature File with Table

The feature file with table keyword is as follows −

Feature − User Registration
Scenario − User enters registration details
   When User enters name and password
      | name |password |
      | t1   | pwd     |
      | t2   | pwd1    |
Then user should be able to complete registration

A table is accessible to the implementation Python code with the .table attribute within the context variable (passed in the step function). A table is an instance of Table.

Implementation logic for Table

Given below is an implementation logic for .table attribute in Table −

@when( User enters name and password )
def step_impl(context):
   for r in context.table:
      model.delete_usr(name=r[ name ], password=r[ password ])

Step Data – Text

A block of text after a step enclosed in """ will be pnked with that step. Here, the indentation is parsed. All the whitespaces at the beginning are removed from the text. Also, all the succeeding pnes must have at least a minimum whitespace as the starting pne.

A text is accessible to the implementation Python code with the .text attribute within the context variable (passed in the step function).

Feature File with Text

The feature file with text keyword is as follows −

Feature − Verify book name added in Library
   
   Scenario − Verify Book name
      Given Book details
         """
          Text added for a step
         """
      Then Verify book name

Tags

A section of a feature file can be tagged so that the Behave is capable of verifying only a certain section of the feature file. A Scenario, Feature, Scenario Outpne can only be tagged.

Also, a tag which is used for a feature shall be inherited by all its Scenarios and Scenario Outpnes. Tags are placed before a Scenario or a Feature that we want to tag. We can also have multiple tags separated by spaces within a pne. A tag begins with @ followed by the tag name.

Feature File with tags

The feature file with tags keyword is as follows:

@payment
@high
Feature − Payment Process
      Scenario − Credit card transaction
   Given user is on credit card payment screen
   Then user should be able to complete credit card payment

Tags help to manage the test execution by excluding/including the specific scenarios or features depending on the tag.