Tutorial by Examples

This example will go over the basic structure of a Cucumber feature file in Gherkin. Feature files use several keywords in the basic syntax. Lets look at the basic keywords: Feature: this keyword signifies that what follows is a basic description or name of the feature being tested or documented...

When writing Gherkin, there may be times in which you want to parameterize your steps for reusability by the engineer who is implementing the test plans. Steps receive parameters through regular expression capturing groups. (Engineering Note: If you do not have matching parameters for each capturing...

As you may have noticed in the example above, we are rewriting the same step multiple times: Given the user is on the login page This can be exceptionally tedious, especially if we have more than one given step that is reused. Gherkin provides a solution for this by giving us another keyword to ...

In some cases you may want to rerun the same scenario over and over, substituting out the arguments. In this case, Gherkin provides several new keywords to accommodate this situation, Scenario Outline: and Example:. The Scenario Outline keyword tells Cucumber that the scenario is going to run multip...

For the purposes of documentation, you may want to filter test plans or scenarios by categories. Developers may want to run tests based on those same categories. Gherkin allows you to categorize Features as well as individual Scenarios via the user of Tags. In the example below, notice the above the...

Each scenario tests one behaviour Scenarios are written in a declarative way Avoid incidental details inside the scenario Omit the obvious Avoid conjunctive steps Keep your scenarios short Don’t have to many scenarios in the same feature Use descriptive scenario names Have only one When st...