extent-config.xml

 

Introduction to Gherkin:

·         Gherkin document is also known as feature file and will have name followed by. feature extension

·         Each Line in a Gherkin document start with one of the Gherkin keywords.

·         Single line comments are only allowed comments starting with # before it.

·         Block comment is not supported by Gherkin.

·         Indentation is supported by tab or two spaces.

Keywords (Alphabetic):

1.       Feature

2.       Rule

3.       Example / scenario

4.       Examples / scenarios

5.       Given

6.       When

7.       Then

8.       And

9.       But

10.   Background

11.   Scenario Outline / Scenario Template

Keywords (Symbolic):

1.       “ ” ” èDoc Strings

2.       | èData Tables

3.       @ èTags

4.       # èComments

 

 

Feature:

It describes the application feature and can have one or more scenarios belonging to same feature.

This the first keyword in any gherkin document /feature file

Feature keyword should followed by : and then the short description of the feature, After that in next line a very brief description can optionally be provided

These description files are ignored by cucumber at run time but improve the feature readability, allows to capture acceptance criteria or business rules and are available for reporting.

Example:

Feature: User Login

                User Login feature describes how a user with valid credentials can log in to the system.

                User must enter valid credentials in login page.

                On click of login button user should navigate to home page

Feature section ends when another keyword starts. Tags can be placed above feature for grouping them.

We should have one feature in a. feature file.

 Example / Scenario:

It describes a rule through the list of steps. To define the example or scenarios multiple steps are added.

Each Example or scenario is going to get executed as test

It follows Given, When, then pattern

·         Given: Describe an initial context

·         When:  Describe an event/ action

·         Then: Describe an expected outcome

Try in some online gherkin editor

Example:

Scenario:

Each step can start with Given, When, Then, And , But

Steps mentioned in an example is executed in the order they are mentioned.

For each step corresponding step definition should be present, We cannot have same step definition with different keyword in an example, in below screenshot last two lines are considered as duplicate steps.

Rule:

It represents one business rule that is going to be implemented. It provides additional information for the feature. It can have multiple scenarios that belong to the rule.

Two  or more scenarios/example specifies the same rule.

 

Feature: Login

  Rule: Only valid credentials are allowed

    Scenario: Login with valid credentials

      Given user navigates to the application www.xyz.com

      When in login page user enters valid username as “qaautomationclasses” and password as “classes”

      And the user clicks on the login button.

      Then login should be successful.

 

    Scenario: Login with invalid credentials

      Given user navigates to the application www.xyz.com.

      When in login page user enters invalid username as “qaautomationclasses12345” and password as “classes675”

      And the user clicks on the login button.

      Then login should not be successful.

Given:

It describes precondition for your test or initial context of the application. Multiple given conditions can be combined with And/But

When: It describes an action or any interaction with application user can interact or any other system can interact with system

User interaction with application: entering valid credentials and click on login

System interaction with application: get the authentication details from authentication provider (google/ms oauth flow)

Then:

It describes expected outcome because of user/system interaction defined in when.

In step definition Assertion should be used to verify expected outcome with actual outcome

Output should be observable like any report or message not like behavior buried deeply inside system like inserting an entry to a database table. (When designing  API tests we might need to verify dbs)

And /But:

Multiple successive Given and Then can be replaced with And /But

NOTE: We have been using And with When but as a better practice we should get rid of And with When

Successive Given , Then can be replaced by "And" as below

When multiple points to be described as a list then we can use * instead of and which gives better readability

Can be replaced as below

Background:

Lets say we have multiple scenarios or examples inside a feature file and for all of then there are common given step/steps then instead of repeating those given statements we can move them to a section called background

Steps mentioned in background is going to get executed before each scenario but after Before hook if specified

Background is placed before first scenario / example

Feature: Login

  Background:

    Given user Opens browser

    And user navigates to the application www.xyz.com

 

  Example: Login with valid credentials

    When in login page user enters valid username as “qaautomationclasses” and password as “classes” and clicks on login button

    Then login should be successful

    And user home page should be displayed

 

  Example: Login with invalid credentials

    When in login page user enters invalid username as “qa123” and password as “class” and clicks on login button

    Then invalid login details warning message should be displayed

    And application should stay on the user login page

Scenario Outline / Scenario Template:

It is used to run same scenario multiple times with different set of values

Fields for which values needs to be passed can be enclosed in < >