Cucumber Testing Guidelines

What is Cucumber Framework?

Cucumber is a testing framework which supports Behavior Driven Development (BDD). It lets us define application behaviour in plain meaningful English text using a simple grammar defined by a language called Gherkin. Gherkin is the language that Cucumber uses to define test cases. It is designed to be non-technical and human-readable, and collectively describes use cases relating to a software system. The purpose behind Gherkin's syntax is to promote Business Driven Development practices across an entire development team, including business analysts and managers.

Bad Example

# BAD EXAMPLE! Do not copy.
Feature: Google Searching

  Scenario: Google Image search shows pictures
    Given the user opens a web browser
    And the user navigates to "https://www.google.com/"
    When the user enters "cucumber" into the search bar
    Then links related to "cucumber" are shown on the results page
    When the user clicks on the "cucumber" link at the top of the results page
    Then images related to "cucumber" are shown on the results page

Note: This scenario is terribly wrong. All that happened was that the author put BDD buzzwords in front of each step of the traditional test. This is not behavior-driven, it is still procedure-driven.
After the Given step, there are two When-Then pairs. This is syntactically incorrect: Given-When-Then steps must appear in order and cannot repeat.
Any single When-Then pair denotes an individual behavior.

Correct Example Gherkin

Feature: log in to Admin UI successfully and validate homepage permissions for the given users

Background: In order to do functional testing of User Permissions

As a functional tester

I want to test Admin UI login page

@BDD

Scenario Outline: Test User Permissions for homepage

Given User is on Login Page

When User enter the "<Username>" and "<Password>"

Then User should be able to login successfully

And Should be able to view homepage "<Component>" applicable to each user permission

Examples:

| Username | Password | Component |

| HeeAdmin | z7D2a | People,Posts,Programmes,Assessments |

| HeeAdminSensitive | y6E4b | People,Posts,Programmes,Assessments |

| HeeAdminRevalidation | x5F6c | People,Posts,Programmes,Concerns,Assessments |

| HeeTisAdmin | w4G8d | People,Posts,Programmes,Concerns,Assessments,Admin |

N.B.

All features must be written in the same format
Screens and links must be consistently labelled throughout all tests
Links must be written in camel case

Test Data

Configuration Data:

Config data pertain to the test environments, not the test cases. Test automation should never contain hard-coded values for config data like URLs, usernames, or passwords. Rather, test automation should read config data when it launches tests and makes references to the required values. This should be done in Before hooks and not in Gherkin steps. In this way, automated tests can run on any configuration, such as different test environments before being released to production. Config data can be stored in data files or accessed through some other dependency.

Config data can be used to select test values to use at runtime. For example, different environments may need different test value data files. Conversely, scenario tagging can control what parts of config data should be used. For example, a tag could specify a username to use for the scenario, and a Before hook could use that username to fetch the right password from the config data.

Test case Values:

The most basic way to specify test case values is directly within the behaviour scenarios themselves! The Gherkin language makes it easy – test case values can be written into the plain language of a step, as step parameters, or in Examples table like above example when and Then steps have the parameter for username, password and component, which will use different values from the table.