BDD & Gherkin Fundamentals
Behaviour-Driven Development bridges the language gap between business, development, and QA. Gherkin syntax turns plain-English specifications into executable tests. Learn to write scenarios that define what works, not how it works.
1 The Hook — Why This Matters
A product manager writes requirements. A developer codes. A QA tester writes a 47-step manual test case. A bug escapes. The question gets asked: "But wasn't this covered?" The answer: yes, but three different people interpreted it three different ways.
In 2023, a major NZ bank's card payment flow had a bug: partial refunds failed silently but marked transactions as complete. Every stakeholder agreed the requirement was "refunds must succeed." But nobody had written down what "succeed" meant: was it immediate validation, asynchronous confirmation, or merchant notification? Developers and QA guessed. A customer lost $12,000 to a refund that the system said worked but didn't.
BDD and Gherkin solve this. They force a shared conversation before code exists. Everyone agrees on concrete examples. Tests are written in plain English that a business analyst can read. Those same tests automate when code is ready. No guessing. No gap.
2 The Rule — The One-Sentence Version
BDD turns business requirements into executable examples before code is written, using a shared language everyone can read and understand.
Behaviour-Driven Development has three layers: Discovery (what should it do?), Formulation (write concrete examples in Gherkin), and Automation (make those examples executable tests). Gherkin is the glue. It's structured English with a precise syntax: Feature, Scenario, Given, When, Then. Each keyword has a specific purpose. No keywords, no precision.
3 The Analogy — Think Of It Like...
A recipe that both a chef and a food critic can read.
A vague recipe says "make a good sauce." A good chef might succeed, but a bad one will fail. A precise recipe says: "Heat 2 tbsp butter, add 1 diced onion, cook for 3 minutes until soft." A chef can follow it. A critic can taste the result and verify it matches. Gherkin is the precise recipe. The Given-When-Then steps are the exact measurements. They leave no room for interpretation.
4 Watch Me Do It — Step by Step
Let's write a complete feature file for an e-commerce checkout flow. We'll build it piece by piece.
Step 1: Define the Feature and Context
The Feature: keyword describes what product behaviour you're testing. Write it as a user benefit, not a technical implementation.
Feature: E-commerce checkout process As a customer I want to pay for items in my basket So that I can receive my order
Step 2: Write the First Scenario
Each Scenario: is one concrete test case. Start with the happy path. Use Given to set up preconditions, When for the action, Then for the expected outcome.
Scenario: Customer completes a successful card payment Given the customer has 2 items in their basket totalling $47.50 And the customer is on the payment page When the customer enters valid card details (Visa, expiry 12/28) And clicks the "Pay Now" button Then the payment is processed successfully And the customer sees a confirmation page with order number And an order confirmation email is sent to their email address
Step 3: Add Edge Cases
Real testing needs error scenarios. Write additional scenarios for failures and edge cases.
Scenario: Card payment fails due to insufficient funds Given the customer has items totalling $47.50 in their basket When the customer enters a card with insufficient funds And clicks the "Pay Now" button Then the payment is declined And the customer sees an error: "Payment declined. Please try another card." And the basket remains unchanged And no order is created Scenario: Partial refund is processed correctly Given an order exists with total $100.00 and was paid via card When a support agent initiates a partial refund of $25.00 Then the customer receives confirmation of the refund And the refund appears on the customer's statement within 2-5 business days And the original order status shows: "Partially refunded ($25.00)"
Step 4: Use Scenario Outline for Data-Driven Tests
When you need to test the same logic with different data, use Scenario Outline: with Examples:
Scenario Outline: Different payment methods are accepted
Given the customer has an item worth $<price> in their basket
When the customer pays with <payment_method>
Then the payment succeeds
And the order is created
Examples:
| payment_method | price |
| Visa | 50.00 |
| Mastercard | 50.00 |
| Amex | 50.00 |
| Apple Pay | 75.50 |
| Google Pay | 120.00 |
Step 5: Use Hooks to Set Up and Tear Down
Before and After hooks run at the start and end of each scenario. Use them to create test data, log in users, or clean up.
Background: Given a test merchant account exists with ID "TEST-MERCHANT-001" And payment gateway is in sandbox mode And the test database is empty @critical @regression Scenario: Checkout flow completes end-to-end # ... your scenario steps ...
@critical, @regression, @smoke to organize your test suite. Run only critical scenarios during pre-deployment checks. Run full regression in CI/CD nightly.
5 When to Use It / When NOT to Use It
✅ BDD is perfect when...
- Requirements are complex or ambiguous
- Multiple teams (dev, QA, BA) need shared understanding
- You are building user-facing workflows
- Regression testing must be reliable and maintainable
- You need executable documentation
- Acceptance criteria come from product managers
❌ Avoid BDD when...
- Testing low-level unit logic (use unit tests)
- Requirements are trivial or fully documented
- Test scripts change daily (too much maintenance)
- No one on your team understands Gherkin (training cost)
- You're testing systems that don't have a user interface
- Your team prefers raw automation code
6 Common Mistakes — Don't Do This
🚫 Writing technical Given-When-Then steps
I used to write: "Given the API endpoint /api/payments is mocked to return 200 OK..."
Actually write: "Given the customer has $50.00 in their account..." A non-technical product manager should be able to read your scenarios. If they can't, you've written code comments, not BDD specs.
🚫 Using abstract examples instead of concrete ones
I used to write: "When the customer enters a valid payment method..." What is valid? CVV 123? Expiry 2099?
Actually write: "When the customer enters card number 4242424242424242, expiry 12/28, CVV 123..." Concrete examples catch ambiguities fast. They also make test data setup deterministic.
🚫 Writing dependent scenarios (Step 1 → Step 2 → Step 3)
I used to write: "Create order" then "Pay for order" then "Verify confirmation." Each scenario must be independent. If the first fails, the second can't run.
Actually: Use Background or a hook to set up preconditions for each scenario. Every test should run in isolation.
🚫 Scenarios that are too broad or too granular
Too broad: "The entire checkout process works." Too granular: "The textbox accepts alphabetic characters" (this is a unit test, not a BDD spec).
Sweet spot: "Customer completes payment with a card." One user action, one meaningful outcome.
7 Now You Try — Scenario Writing Challenge
Scenario: You're testing a password reset feature. A user clicks "Forgot Password," enters their email, receives a reset link, and sets a new password. Write the happy-path Gherkin scenario in the format we've covered (Feature, Given, When, Then).
Write your scenario before revealing the reference answer.
Reference Scenario:
Feature: Password reset As a user who forgot my password I want to reset it via email So I can regain access to my account Scenario: User resets password successfully Given the user has an account with email "john@example.com" And the user is on the login page When the user clicks "Forgot Password" And enters "john@example.com" in the email field And clicks "Send Reset Link" Then a password reset email is sent to "john@example.com" And the user sees a confirmation message: "Check your email for a reset link" When the user clicks the reset link in the email Then the user sees a "Set New Password" form When the user enters password "NewSecure#123" (twice) And clicks "Reset Password" Then the password is updated successfully And the user is logged in And the user can navigate to their account dashboard
Your scenario might differ slightly, but it should: (1) be concrete (real email, real password), (2) use Given for preconditions, (3) chain When-Then pairs, and (4) have a single main outcome per scenario.
8 Self-Check — Can You Actually Do This?
Click each question to test your understanding. If you answer all three correctly, you're ready to drive BDD in your team.
Q1. What is the difference between a Scenario and a Scenario Outline?
Scenario: A single test case with one set of fixed data. Scenario Outline: A template that runs multiple times with different data from the Examples table. Use Outline when you're testing the same logic with multiple inputs (e.g., different card types, different amounts, different currencies).
Q2. Why should a non-technical person be able to read your Gherkin?
Because BDD is about shared understanding. If the product manager, developer, and tester can't all read and agree on the scenario, it hasn't achieved its purpose. Gherkin forces you to avoid implementation details (like "mock the API" or "insert into the database") and focus on user-facing behaviour instead.
Q3. What tools are commonly used to run Gherkin scenarios?
Cucumber (Java, Ruby, JavaScript), SpecFlow (.NET), Behave (Python), Robot Framework (keyword-driven, supports any language). Choose based on your tech stack. All of them parse Gherkin and map steps to code (step definitions). They all integrate with CI/CD and generate reports.
9 Interview Prep — Common Questions
Q. "What's the difference between BDD and traditional test automation?"
Traditional automation often starts with developers writing Selenium scripts in Python/Java. They're powerful but opaque to non-technical stakeholders. BDD starts with business examples written in Gherkin before code exists. Those examples become the acceptance criteria. Then developers write the step definitions to make them pass. The advantage: requirements, tests, and documentation are all the same artefact. The disadvantage: overhead if requirements are trivial or rarely change.
Q. "Who writes the Gherkin scenarios?"
In mature BDD teams, the BA, developer, and QA collaborate to write scenarios together (the Three Amigos). The BA brings the business requirement, the developer spots implementation risks, the QA ensures test coverage. In reality, often the QA or BA writes the first draft, then the team refines it together. Developers never write Gherkin alone—that defeats the shared understanding goal.
Q. "How do you handle flaky BDD tests?"
Flaky BDD tests usually come from: (1) timing issues (use explicit waits, never sleep), (2) missing test data setup (use hooks to ensure preconditions), (3) poorly written steps that assume specific UI state (make steps idempotent), (4) external dependencies like payment gateways (mock or use sandboxes). The Gherkin is usually fine; the step definitions are the problem. Tag flaky tests with @flaky, review the step definitions, and add explicit waits and error handling.
Q. "How do you maintain BDD scenarios over time?"
As features evolve, scenarios become stale. Treat them like code: (1) Version control (Git), (2) review on pull request (product team must approve changes), (3) run in CI/CD on every commit, (4) retire old scenarios that no longer reflect reality. A scenario that fails but nobody fixes is worse than no scenario. Schedule quarterly reviews to remove dead scenarios and update examples to match current product behaviour.
Q. "What's the ROI of BDD vs traditional test automation?"
Short term: BDD is more expensive (writing Gherkin takes time, team alignment takes meetings). Medium term: clearer specs reduce rework and miscommunication. Long term: executable specs double as documentation, reducing onboarding time. In my experience: BDD pays off after 6 months on projects with complex, ambiguous requirements. For simple CRUD apps or low-touch projects, the overhead isn't worth it. Choose wisely.