bdd-methodologylisted

# BDD Methodology ## Overview Behaviour-Driven Development translates acceptance criteria into executable specifications. Gherkin scenarios are the contract between the business (what it expects) and the engineer (what to implement). **Core rule:** Every word in a Gherkin scenario must be understood by a domain expert who has never seen code. ## Mapping AC → Gherkin Each acceptance criterion produces one or more scenarios. The mapping is explicit and traceable. | AC type | Gherkin pattern | |---|---| | Happy path | `Scenario: {persona} {action} successfully` | | Boundary condition | `Scenario: {persona} {action} at the limit` | | Rejection / business rule violation | `Scenario: {persona} is rejected when {condition}` | | Multiple inputs (parametrized) | `Scenario Outline` with `Examples` table | **Mapping process:** 1. Read the AC — identify: **persona**, **action**, **expected outcome** 2. Identify the **precondition** → Given (state of the world before the action) 3. Identify the **trigger** → When (ONE business action only) 4. Identify the **observable result** → Then (business-visible outcome, never internal state) ## Gherkin Patterns ### Basic Scenario ```gherkin Feature: Eligibility Check @eligibility @happy-path Scenario: Driver with a clean record obtains eligibility Given a driver with 5 years of experience and no accidents When the driver requests an eligibility check Then the driver is declared eligible And the eligibility certificate