Skills / Engineering

Behavior-Driven Development (BDD)

I started using the word 'behaviour' in place of 'test' in my dealings with TDD, and I immediately found that teams started to have more meaningful conversations about their software.

Behavior-Driven Development (BDD), created by Dan North in 2003–2006, replaces ambiguous requirements with concrete, structured examples expressed in plain language. Using the Given-When-Then scenario format and the Three Amigos collaboration model, it ensures developers, testers, and business stakeholders agree on exactly what a feature should do — before a line of code is written. The result is living documentation that doubles as an automated test suite.

By Dan North  ·  Free

Use this skill See it in action

Specimen 01 · Live diagnosisBehavior-Driven Development (BDD)

Input

“Sure. Our story is: 'As a customer, I want to reset my password so that I can regain access to my account.' The acceptance criteria just say 'user…”

Diagnosis

I apply Dan North's Behavior-Driven Development methodology — meaning we express every feature as concrete Given-When-Then scenarios before any code is written.

Full transcript ↓

Calibrated referenceagent-skills.ai

The gap

Turn vague acceptance criteria into executable scenarios developers, testers, and business stakeholders all own

BDD prescribes a four-step lifecycle for every feature: Discover → Specify → Automate → Implement. Discovery begins with a Three Amigos session — a business analyst, a developer, and a tester meet before any code is written to surface assumptions through concrete examples. Those examples are formalized using the Given-When-Then (GWT) scenario structure in Gherkin, a plain-language syntax understood by both humans and tools like Cucumber and SpecFlow. Development proceeds outside-in: acceptance scenarios drive integration tests, which drive unit tests — ensuring every line of code is traced back to a stated behavior. The resulting feature files become living documentation: because they are executable, they can never drift out of sync with the actual system.

The problem

Requirements get lost in translation between business and engineering. Acceptance criteria written as vague prose lead to mismatched expectations, last-minute scope debates, and regression bugs that should have been caught before coding started. Teams that rely on test-after verification discover ambiguities only when fixing them is expensive — after code has been written and deployed.

The solution

Express every feature as concrete, executable examples before writing code — so that business stakeholders, developers, and testers are looking at exactly the same specification, in plain language, that the automated test suite will enforce forever.

You bring

A user story, feature request, or vague requirement you need to clarify
Existing acceptance criteria, test cases, or specification documents to convert to BDD
Gherkin scenarios you've already written that need quality review
An upcoming story refinement meeting you need to prepare discovery questions for

You get

Well-formed Given-When-Then scenarios covering happy path, edge cases, and negative cases
A complete Gherkin feature file ready for automation with Cucumber, SpecFlow, or JBehave
An Example Mapping table surfacing rules, concrete examples, and open questions for Three Amigos sessions
Actionable feedback on scenario anti-patterns: imperative UI coupling, compound scenarios, missing Given context

In action

Watch the methodology work.

Three specimens from a single real session: the same situation, unaided and calibrated, the full transcript, and the skill answering live in the channel where the work happens.

Fig.01  —  The same situation, two ways

Specimens A · B

Specimen AVague

Unaided

“Your story card says 'Users can reset their password' with one acceptance criterion: 'password reset works.' The developer builds a flow. The QA engineer finds three edge cases in regression. The security team flags that the error message reveals whether an email is registered. The feature gets bounced back two days before release for a hotfix and an emergency design review.”

×Vague — nothing concrete to act on.

Specimen BCalibrated

With Behavior-Driven Development (BDD)

“Before a line of code is written, a 30-minute Three Amigos session produces a Gherkin feature file with six scenarios covering happy path, expiry, reuse prevention, security-safe error messages, and password strength validation. The security requirement is a named scenario every stakeholder reviewed and signed off on. Automation is wired before implementation begins. The feature ships without last-minute surprises — and when the expiry policy changes from 1 hour to 24 hours six months later, a single Given clause update shows exactly what to retest.”

◦Specific, grounded, and ends with one clear next step.

Fig.02  —  A real session, unedited

In-app · assistant

Behavior-Driven Development (BDD)Claude

Behavior-Driven Development (BDD)

I apply Dan North's Behavior-Driven Development methodology — meaning we express every feature as concrete Given-When-Then scenarios before any code is written. These scenarios become both your acceptance criteria and your automated test suite. What are you working on? You can paste a user story, a ticket description, or vague acceptance criteria — I'll turn it into Gherkin and surface the behavioral questions your team needs to answer before development starts.

Sure. Our story is: 'As a customer, I want to reset my password so that I can regain access to my account.' The acceptance criteria just say 'user can reset their password.' That's all we have.

Classic Three Amigos discovery moment — that acceptance criterion is a goal, not a specification. At least six distinct behaviors are hiding in that single sentence. Before writing any scenarios, let me ask the key questions your developer, tester, and BA need to agree on:

What triggers the reset — a link emailed to the address on file, or a code sent by SMS?2. How long is the reset link valid?3. What happens if the email address isn't registered? (Security teams often have opinions here.)4. Can the same reset link be used twice?5. What are the password strength rules?

Which of these do you have answers to, and which are still open?

Link is emailed, expires in 1 hour, must be single-use. The error message for unknown emails should NOT reveal whether the account exists — that's a security requirement. Password must be 8+ characters with at least one number.

The security requirement on unknown emails is the kind of rule that almost never makes it into prose acceptance criteria — but it's a named behavior we can encode as a concrete scenario. Here's your feature file:

```gherkinFeature: Password Reset As a customer who has forgotten their password I want to reset it via email So that I can regain access to my account

Scenario: Reset link sent for registered email Given a customer with email "user@example.com" has an account When the customer requests a password reset for "user@example.com" Then a reset link is sent to "user@example.com"

Scenario: Reset link request for unregistered email (security-safe) Given no account exists for "ghost@example.com" When the customer requests a password reset for "ghost@example.com" Then no email is sent And the response message is "If an account exists for this email, a reset link has been sent"

Scenario: Customer sets a valid new password within the expiry window Given a customer has received a valid, unused reset link less than 1 hour old When the customer sets a new password "NewPass42" Then the customer is logged in successfully And the reset link is invalidated

Scenario: Reset link cannot be reused Given a customer has already used a reset link to change their password When the customer tries to use the same reset link again Then they see: "This reset link has already been used"

Scenario: Expired reset link is rejected Given a customer has a reset link that was generated 61 minutes ago When the customer tries to use the link Then they see: "This reset link has expired"

Scenario: Password does not meet strength requirements Given a customer has a valid unused reset link When the customer tries to set the password "short" Then they see: "Password must be at least 8 characters and include a number" And the password is not changed```

Notice that none of these steps describe UI interactions — no 'click the button' or 'fill in the form.' These scenarios specify behavior, so they'll remain valid even after a full UI redesign.

This is way more thorough than what we had. How do we know we haven't missed anything?

Here's an Example Mapping table to check coverage. Each row is a business rule; each column is a covered scenario or a remaining open question:

| Rule | ✅ Covered | ❓ Still Open ||---|---|---|| Link sent on request | Scenario 1 | — || Unknown email → safe response | Scenario 2 | — || Link expires after 1 hour | Scenario 5 | Boundary: exactly 60 min old? || Link is single-use | Scenario 4 | — || Password strength: 8+ chars + 1 number | Scenario 6 | Special characters? Max length? || Successful reset logs user in | Scenario 3 | Should prior sessions be invalidated? |

Two open questions remain. The 60-minute boundary is a step implementation question — your team decides whether the test uses `>= 60` or `> 60`. Session invalidation is a security decision. Want to resolve that one and add the scenario, or should I flag it as an open question in the feature file header?

Sessions should be invalidated. Let's add that scenario.

Here's the scenario to append:

```gherkin Scenario: All existing sessions invalidated after password reset Given a customer is logged in on two devices And the customer resets their password using a valid reset link When the password change is confirmed Then all existing sessions for that customer are terminated And only the current session remains active```

The feature file now fully specifies the security intent — any developer picking this up six months from now will understand why sessions are invalidated, not just that they are. Your Example Mapping table is clear: all six rules have at least one covered scenario and no open questions remain. This is ready for your automation engineer to wire up step definitions.

Reply to Behavior-Driven Development (BDD)…

What the skill is doing

01Given-When-Then Scenario Writer

02Acceptance Criteria Converter

03Three Amigos Session Facilitator

Fig.03  —  The same skill, in the channel you already use

WhatsApp · live

9:41

BDBehavior-Driven Development (BDD)typing…

Messages are end-to-end encrypted. No one outside of this chat can read them.

Today

Sure. Our story is: 'As a customer, I want to reset my password so that I can regain access to my account.' The acceptance criteria just say 'user can…9:14✓✓

I apply Dan North's Behavior-Driven Development methodology — meaning we express every feature as concrete Given-When-Then scenari…9:14

These scenarios become both your acceptance criteria and your automated test suite.9:15

Message

The same skill, where the work happens.

No new app to learn. The methodology runs over the WhatsApp Business API, so the answer lands as a reply in the thread you’re already in — same rigour, zero context-switch.

◦Reads the situation, names the pattern, returns one concrete next move.

◦Delivered in seconds, inside a conversation that already exists.

Specimen · WhatsApp Business API · live

Capabilities

What it does, specifically.

Each capability is a distinct move drawn straight from the source methodology — not a generic assistant guessing.

CapabilityC-01

Given-When-Then Scenario Writer

Transforms a user story or feature description into well-formed BDD scenarios using the rigid three-part GWT structure. Produces a happy-path scenario, at least one edge case, and one negative/failure case for every feature — ensuring full behavioral coverage before development starts.

◦ MethodBased on North's Given/When/Then template from 'Introducing BDD' (2006), which prescribes that every scenario begins with preconditions (Given), describes a single triggering action (When), and asserts observable outcomes (Then) — with no concern from one clause ever bleeding into another.

CapabilityC-02

Acceptance Criteria Converter

Takes existing acceptance criteria written in prose, bullet lists, or test-case format and rewrites them as atomic, concrete Given-When-Then scenarios. Flags criteria that are too vague to specify (e.g., 'the system should be fast') and prompts for the specific threshold or observable outcome needed to make them automatable.

◦ MethodImplements North's principle that acceptance criteria must be expressed as verifiable examples — 'executable specifications' — rather than abstract goals. Vague criteria cannot be automated and create the exact misalignment BDD was designed to eliminate.

CapabilityC-03

Three Amigos Session Facilitator

Prepares and guides the discovery conversation between a business analyst, developer, and tester before a story enters development. Generates targeted example questions, surfaces boundary conditions and security edge cases, and produces an Example Mapping table distinguishing rules, concrete examples, and open questions that need answers before coding begins.

◦ MethodBased on North's Three Amigos collaboration model, which mandates pre-implementation discovery among business, development, and testing roles to surface assumptions through concrete examples — preventing the misalignments that cause rework late in the sprint.

CapabilityC-04

Scenario Quality Reviewer

Analyzes existing Gherkin scenarios for the most common BDD anti-patterns: imperative step-by-step UI instructions instead of declarative behavior descriptions, over-specified UI coupling that makes tests brittle, compound 'And' chains hiding multiple behaviors, missing Given context, and assertions that can't be verified without reading implementation code.

◦ MethodApplies North's declarative-over-imperative principle — that BDD scenarios must describe what the system does at the business level, not how a user operates the interface — which he identified as the primary source of brittle, maintenance-heavy test suites.

CapabilityC-05

Gherkin Feature File Generator

Produces a complete, automation-ready Gherkin feature file from a description or set of scenarios, including Feature title, role-benefit-business narrative (As a / I want / So that), Background section where shared context applies, and a full Scenario suite with Scenario Outline and Examples tables for data-driven cases.

◦ MethodImplements the Gherkin syntax North designed for JBehave, which became the lingua franca for all major BDD tools — Cucumber (Ruby/Java/JS), SpecFlow (.NET), Behat (PHP), and Behave (Python) — ensuring generated files are immediately usable across any stack.

Tested

Graded before it shipped.

Every skill is scored against independent scenarios for methodology fidelity before it goes live — not vibes, a rubric.

What it produces

OutputD-01

Gherkin Feature File

A complete, tool-ready .feature file with Feature narrative, Background context, and a full Scenario suite (happy path, edge cases, negative cases, Scenario Outlines where appropriate). Paste directly into your Cucumber, SpecFlow, or JBehave project and wire up step definitions.

OutputD-02

Example Mapping Table

A structured table separating business rules (yellow), concrete examples per rule (green), open questions blocking specification (red), and out-of-scope items — the exact output of a Three Amigos session, ready to drive story refinement.

OutputD-03

Scenario Anti-Pattern Audit

A line-by-line review of existing scenarios flagging imperative style, UI coupling, compound steps, and missing context — with rewritten BDD-compliant alternatives and explanations of why each anti-pattern creates maintenance burden.

OutputD-04

Acceptance Criteria Conversion Report

Side-by-side mapping of original prose acceptance criteria to their Given-When-Then equivalents, with notes on assumptions made explicit, ambiguities resolved, and criteria too vague to automate without further discovery.

The source

Grounded in the original work.

Every answer traces back to a real source and the practitioner who wrote it — not a secondhand summary. Here is the source of record.

Source authorA-01

Dan North

Dan North coined the term 'Behavior-Driven Development' in 2003 and published the foundational article 'Introducing BDD' in Better Software Magazine in 2006. He created JBehave, the first BDD testing framework, which directly inspired Cucumber, SpecFlow, and Behat. His core insight — that TDD's value lies in specifying behavior rather than writing tests — transformed how agile teams write requirements and acceptance criteria. North is an international conference speaker at QCon, Agile, and GOTO, and has spent two decades teaching BDD practices to engineering organizations worldwide.

Status · Inspired by Dan North’s work — not yet claimed. Are you Dan North?

Primary sourceS-01

Introducing BDD (Better Software Magazine, 2006) and dannorth.net

by Dan North

Creator of BDD (2003); originator of Given-When-Then and the Three Amigos model; author of JBehave; keynote speaker at QCon, GOTO, and Agile conferences.

Read the original ↗

Citationdannorth.net

In the build queue

Be first to run it.

Behavior-Driven Development (BDD) is being built right now. Leave your email and we’ll tell you the moment it goes live.

Notify meEmail

At launchI have a user story that needs to be turned into BDD scenarios before we start coding. Here it is: [paste your story]. My acceptance criteria are vague — can we run through the Three Amigos questions to surface the concrete examples first?