Gherkin Vocabulary

Gherkin's Given/When/Then structure maps to test anatomy: Given sets up the initial context or precondition ('Given the user is logged in'), When describes the action or event ('When the user clicks Submit'), and Then states the expected outcome ('Then a confirmation email is sent'). This structure makes tests readable by non-technical stakeholders.

The Feature keyword describes the high-level software capability being specified. It's the title and description at the top of a .feature file. All scenarios in the file relate to this feature. Example: 'Feature: User registration'. The feature description provides context but is not itself executed — it's documentation.

A Scenario Outline uses angle-bracket placeholders (e.g., ) and an Examples table with multiple data rows. The scenario is executed once for each row, substituting the placeholders with row values. This is the Gherkin equivalent of parameterised tests — one scenario template, multiple test cases.

Background in Gherkin defines common setup steps that apply to all scenarios in the file. Instead of repeating 'Given the user is logged in' in every scenario, you put it once in Background and it runs before each scenario. It keeps scenarios concise and avoids duplication.

Step definitions are the glue between Gherkin scenarios and executable test code. Each step definition is a function annotated with a regex or expression that matches Gherkin step text. When Cucumber/SpecFlow runs a scenario, it finds the matching step definition and executes its code. This separation allows the Gherkin to remain readable while the implementation details live in code.