Gherkin is a line-oriented language that uses indentation to define structure. Line endings terminate statements (called steps) and either spaces or tabs may be used for indentation.

It is a domain specific language which helps you to describe business behavior without the need to go into detail of implementation. This text acts as documentation and skeleton of your automated tests. Gherkin is based on TreeTop Grammar which exists in 37+ languages. Therefore you can write your gherkin in 37+ spoken languages.

Gherkin serves two purposes: serving as your project’s documentation and automated tests.

Feature: Some terse yet descriptive text of what is desired
  In order to realize a named business value
  As an explicit system actor
  I want to gain some beneficial outcome which furthers the goal

  Scenario: Some determinable business situation
    Given some precondition
      And some other precondition
     When some action by the actor
      And some other action
      And yet another action
     Then some testable outcome is achieved
      And something else we can check happens too

  Scenario: A different situation

The parser divides the input into features, scenarios and steps. Let’s walk through the above example:

1. Feature: Some terse yet descriptive text of what is desired starts the feature and gives it a title. Learn more about features in the “Features” section.
2. Scenario: Some determinable business situation starts the scenario, and contains a description of the scenario. Learn more about scenarios in the “Scenarios” section.
3. The next 7 lines are the scenario steps, each of which is matched to a regular expression defined elsewhere. Learn more about steps in the “Steps” section.
4. Scenario: A different situation starts the next scenario, and so on.
   When you’re executing the feature, the trailing portion of each step (after keywords like Given, And, When, etc) is matched to a regular expression, which executes a PHP callback function. You can read more about steps matching and execution in Defining Reusable Actions – Step Definitions.

Features

Every *.feature file conventionally consists of a single feature. Lines starting with the keyword Feature: (or its localized equivalent) followed by three indented lines starts a feature. A feature usually contains a list of scenarios. You can write whatever you want up until the first scenario, which starts with Scenario: (or localized equivalent) on a new line. You can use tags to group features and scenarios together, independent of your file and directory structure.
Every scenario consists of a list of steps, which must start with one of the keywords Given, When, Then, But or And (or localized one).

Feature: Serve coffee
  In order to earn money
  Customers should be able to
  buy coffee at all times

  Scenario: Buy last coffee

 Given there are 1 coffees left in the machine
    And I have deposited 1 dollar
    When I press the coffee button
    Then I should be served a coffee

Scenarios

Scenario is one of the core Gherkin structures. Every scenario starts with the Scenario: keyword (or localized one), followed by an optional scenario title. Each feature can have one or more scenarios, and every scenario consists of one or more steps.
The following scenarios each have 3 steps:

Scenario: Wilson posts to his own blog
  Given I am logged in as Wilson
  When I try to post to "Expensive Therapy"
  Then I should see "Your article was published."

Scenario: Wilson fails to post to somebody else's blog
  Given I am logged in as Wilson
  When I try to post to "Greg's anti-tax rants"
  Then I should see "Hey! That's not your blog!"

Scenario: Greg posts to a client's blog
  Given I am logged in as Greg
  When I try to post to "Expensive Therapy"
  Then I should see "Your article was published."

Scenario outlines

Scenario outline basically replaces variable/keywords with the value from the table. Each row in the table is considered to be a scenario.

Copying and pasting scenarios to use different values can quickly become tedious and repetitive:

Scenario: Eat 5 out of 12
  Given there are 12 cucumbers
  When I eat 5 cucumbers
  Then I should have 7 cucumbers

Scenario: Eat 5 out of 20
  Given there are 20 cucumbers
  When I eat 5 cucumbers

Scenario Outlines allow us to more concisely express these examples through the use of a template with placeholders:

Scenario Outline: Eating
  Given there are <start> cucumbers
  When I eat <eat> cucumbers
  Then I should have <left> cucumbers

  Examples:
    | start | eat | left |
    |  12   |  5  |  7   |
    |  20   |  5  |  15  |

The Scenario outline steps provide a template which is never directly run. A Scenario Outline is run once for each row in the Examples section beneath it (not counting the first row of column headers).

The Scenario Outline uses placeholders, which are contained within < > in the Scenario Outline’s steps. For example:

Given <I'm a placeholder and I'm ok>

Think of a placeholder like a variable. It is replaced with a real value from the Examples: table row, where the text between the placeholder angle brackets matches that of the table column header. The value substituted for the placeholder changes with each subsequent run of the Scenario Outline, until the end of the Examples table is reached.

So when running the first row of our example:

Scenario Outline: controlling order
  Given there are <start> cucumbers
  When I eat <eat> cucumbers
  Then I should have <left> cucumbers

  Examples:
    | start | eat | left |
    |  12   |  5  |  7   |

The scenario that is actually run is:

Scenario Outline: controlling order
  # <start> replaced with 12:
  Given there are 12 cucumbers
  # <eat> replaced with 5:
  When I eat 5 cucumbers
  # <left> replaced with 7:
  Then I should have 7 cucumbers

Backgrounds

Backgrounds allows you to add some context to all scenarios in a single feature. A Background is like an untitled scenario, containing a number of steps. The difference is when it is run: the background is run before each of your scenarios

Feature: Multiple site support

  Background:
    Given a global administrator named "Greg"
    And a blog named "Greg's anti-tax rants"
    And a customer named "Wilson"
    And a blog named "Expensive Therapy" owned by "Wilson"

  Scenario: Wilson posts to his own blog
    Given I am logged in as Wilson
    When I try to post to "Expensive Therapy"
    Then I should see "Your article was published."

  Scenario: Greg posts to a client's blog
    Given I am logged in as Greg
    When I try to post to "Expensive Therapy"
    Then I should see "Your article was published."

Given:

The use of Given keyword is to put the system in a familiar state before the user starts interacting with the system. However, you can omit writing user interactions in Given steps if Given in the “Precondition” step.

Syntax:

Given

Given - a test step that defines the 'context
Given I am on "/."

When:

When the step is to define action performed by the user.

Syntax:

When

A When - a test step that defines the 'action' performed
When I perform "Sign In."

Then:

The use of ‘then’ keyword is to see the outcome after the action in when step. However, you can only verify noticeable changes.

Syntax:

 Then

Then - test step that defines the 'outcome.'
Then I should see "Welcome Tom."

And & But

You may have multiple given when or Then.

Syntax:

But

A But - additional test step which defines the 'action' 'outcome.'
But I should see "Welcome Tom."

And - additional test step that defines the 'action' performed
And I write  "EmailAddress" with "Tomjohn@gmail.com."

Best practices of using Gherkin

• Each scenario should execute separately
• Every feature should able to be executed along
• Steps information should be shown independently
• Connect your Scenario’s with your requirements
• Keep a complete track of what scenarios should be included in a requirement document
• Create modular and easy to understand steps
• Try to combine all your common scenarios

Advantage and Disadvantages of Gherkin

• Gherkin is simple enough for non-programmers to understand
• Programmers can use it as a very solid base to start their tests
• It makes User Stories easier to digest
• Gherkin script can easily understand by business executives and developers
• Targets the business requirements
• A significant proportion of the functional specifications is written as user stories
• You don’t need to be expert to understand the small Gherkin command set
• Gherkin links acceptance tests directly to automated tests
• Style of writing tests cases are easier to reuse code in other tests

Disadvantage

• It requires a high level of business engagement and collaborations
• May not work well in all scenarios
• Poorly written tests can easily increase test-maintenance cost

Summary

• Gherkin is the format for cucumber specifications
• Gherkin is line-oriented language just like YAML and Python
• Gherkin Scripts connects the human concept of cause and effect to the software concept of input/process and output
• Feature, Background, Scenario, Given, When, Then, And But are importantly used in Gherkin
• In Gherkin cucumber, each scenario should execute separately
• The biggest advantage of Gherkin is simple enough for non-programmers to understand
• It may not work well in all type of scenarios