Page Comparison

Image RemovedImage Added

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! 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.

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.