BDD Gherkin Language

When describes the action or event that triggers the behaviour being tested.

Options A, B, and C all describe states or preconditions — they correctly belong in Given clauses, not When. The Given keyword establishes context; When describes the specific trigger action; and Then describes the observable outcome. "When the user clicks the Confirm Order button" is the triggering event that causes the system to do something, making it the only correct When step here.

Key vocabulary:
• Given — establishes the initial system state or precondition before the action
• When — describes the action, event, or trigger that the scenario is testing
• Then — describes the observable outcome or expected system response
• Scenario — a single concrete example of a feature's behaviour in Gherkin

Declarative Gherkin describes intent; imperative Gherkin describes UI interactions — and imperative creates brittle tests.

The step in the question is imperative: it describes every low-level UI action (which field, which key, which button). When the UI changes — e.g. the label "Log In" becomes "Sign in" — every scenario using this step breaks. A declarative rewrite like "When the user logs in with valid credentials" expresses business intent, is UI-independent, and remains valid as long as the login concept exists. Options A and B are incorrect. Option D confuses a screen action step with a Background precondition.

Key vocabulary:
• Declarative style — describing what the system should do, not how to interact with the UI
• Imperative style — step-by-step UI instructions coupled to the current implementation
• Brittle test — a test that breaks due to unrelated UI or code changes
• Business intent — the goal or outcome from the user's perspective, independent of implementation

Background is Gherkin's built-in mechanism for shared preconditions — it eliminates duplication within a feature file.

Option A duplicates the step 5 times and creates a maintenance burden: change the step once and you must update all 5 scenarios. Option B is not a Gherkin pattern — there is no "setup scenario" linking mechanism. Option D conflates Scenario Outline (parameterised variation of one scenario) with shared preconditions. Option C is correct: a Background block runs its steps before each scenario in the file automatically, keeping scenarios DRY and readable — the shared precondition is maintained in one place.

Key vocabulary:
• Background — a Gherkin block whose steps run before every scenario in the feature file
• DRY (Don't Repeat Yourself) — a design principle that avoids duplicating logic or data
• Scenario Outline — a parameterised Gherkin scenario that runs once per row in an Examples table
• Feature file — the .feature file containing one feature's Gherkin scenarios

Scenario Outline + Examples is the correct pattern for data-driven Gherkin tests.

Option A creates three near-identical files and violates DRY — changing the scenario structure means editing three places. Option B misuses Background, which is for shared preconditions, not data variation. Option D puts multiple test cases into one Then clause, which is non-testable and violates the single-assertion principle. Option C is correct: a Scenario Outline defines the scenario structure once with angle-bracket parameters like <email>, and the Examples table provides one row per data combination — making the test readable, maintainable, and automatically parameterized by Cucumber or similar runners.

Key vocabulary:
• Scenario Outline — a Gherkin template that accepts parameters from an Examples table
• Examples table — the data table beneath a Scenario Outline that provides one test run per row
• Parameters — placeholders written as <name> in a Scenario Outline step
• Data-driven testing — running the same test logic with different input values to increase coverage

A Then step must assert exactly one observable, testable outcome — not chain multiple assertions using "and".

Options A, B, and C are correct Gherkin steps: they each express one clear state, action, or outcome respectively. Option D violates two rules: first, it chains three separate assertions into one step using "and" — each should be its own separate Then or And step. Second, "the user should be happy" is not testable — it is subjective and cannot be verified by an automated or manual test. In professional Gherkin, every assertion must be observable and measurable.

Key vocabulary:
• And / But — Gherkin conjunctions that continue a Given, When, or Then block; each And must belong to one clear assertion
• Testable assertion — an outcome that can be objectively verified (page displayed, email received, status changed)
• Non-testable assertion — a subjective or ambiguous outcome that cannot be measured or automated
• Single-outcome step — the best-practice principle that each Then or And step verifies only one thing