BDD with Cucumber & Gherkin Syntax
Behavior-Driven Development (BDD) bridges the gap between business requirements and automation tests using plain English specifications written in Gherkin syntax. Cucumber is the tool that executes these specifications as automated tests. BDD enables product managers, business analysts, and developers to collaborate on test scenarios before development begins — making requirements unambiguous and verifiable.
Gherkin Syntax and BDD Workflow
- Feature: Describes the feature being tested (one .feature file per feature)
- Scenario: A specific test case in plain English — represents one behavior
- Given: The initial context or precondition (system state before the scenario)
- When: The action the user takes (trigger event)
- Then: The expected outcome (verifiable assertion)
- And / But: Extends Given, When, or Then steps
- Scenario Outline: Parameterized scenario using Examples table for multiple data sets
- Background: Steps that run before every scenario in a feature file
BDD Feature File + Step Definitions
# ══════════════════════════════════════════════════════════════
# features/login.feature — Written by BA, PM, or QA
# Readable by ANYONE — technical or not
# ══════════════════════════════════════════════════════════════
Feature: User Authentication
As a registered user
I want to log in to my account
So that I can access my personalized dashboard
Background:
Given I am on the login page
Scenario: Successful login with valid credentials
When I enter email "alice@example.com"
And I enter password "Test@1234"
And I click the login button
Then I should be redirected to the dashboard
And I should see welcome message "Welcome, Alice"
Scenario: Failed login with wrong password
When I enter email "alice@example.com"
And I enter password "wrongpassword"
And I click the login button
Then I should see error message "Invalid email or password"
And I should remain on the login page
Scenario Outline: Login with multiple user types
When I enter email "<email>"
And I enter password "<password>"
And I click the login button
Then I should be redirected to "<expected_page>"
Examples:
| email | password | expected_page |
| admin@example.com | Admin@1234 | /admin |
| alice@example.com | Test@1234 | /dashboard |
| guest@example.com | Guest@1234 | /guest |
# ══════════════════════════════════════════════════════════════
# step_definitions/login_steps.py — Written by the SDET
# ══════════════════════════════════════════════════════════════
from pytest_bdd import given, when, then, parsers, scenarios
from pages.login_page import LoginPage
from pages.dashboard_page import DashboardPage
scenarios('../features/login.feature')
@given("I am on the login page")
def go_to_login(driver, base_url):
driver.get(f"{base_url}/login")
@when(parsers.parse('I enter email "{email}"'))
def enter_email(driver, email):
LoginPage(driver).enter_email(email)
@when(parsers.parse('I enter password "{password}"'))
def enter_password(driver, password):
LoginPage(driver).enter_password(password)
@when("I click the login button")
def click_login(driver):
LoginPage(driver).submit()
@then(parsers.parse('I should be redirected to "{page}"'))
def verify_redirect(driver, page):
assert page in driver.current_url, f"Expected {page} in URL, got {driver.current_url}"
@then(parsers.parse('I should see welcome message "{message}"'))
def verify_welcome(driver, message):
welcome = DashboardPage(driver).get_welcome_message()
assert message == welcome
@then(parsers.parse('I should see error message "{message}"'))
def verify_error(driver, message):
error_text = LoginPage(driver).get_error_message()
assert message in error_text
@then("I should remain on the login page")
def verify_login_page(driver, base_url):
assert "/login" in driver.current_urlCommon Mistakes
- Writing Gherkin that only developers understand — 'When I POST to /auth/login with payload' is not readable by business users; keep steps business-level
- One step definition per test — step definitions should be reusable across multiple scenarios; 'I enter email' should work for login AND registration
- Not using Background for common setup — repeating 'Given I am on the login page' in every scenario is verbose; put it in Background
- Scenario Outline with only 1 example row — use regular Scenario for single cases; Scenario Outline is for multiple parameterized data sets
Tip
Tip
Practice BDD with Cucumber Gherkin Syntax in small, isolated examples before integrating into larger projects. Breaking concepts into small experiments builds genuine understanding faster than reading alone.
Red → Green → Refactor. Given/When/Then.
Practice Task
Note
Practice Task — (1) Write a working example of BDD with Cucumber Gherkin Syntax from scratch without looking at notes. (2) Modify it to handle an edge case (empty input, null value, or error state). (3) Share your solution in the Priygop community for feedback.
Quick Quiz
Common Mistake
Warning
A common mistake with BDD with Cucumber Gherkin Syntax is skipping edge case testing — empty inputs, null values, and unexpected data types. Always validate boundary conditions to write robust, production-ready software testing code.
Key Takeaways
- Behavior-Driven Development (BDD) bridges the gap between business requirements and automation tests using plain English specifications written in Gherkin syntax.
- Feature: Describes the feature being tested (one .feature file per feature)
- Scenario: A specific test case in plain English — represents one behavior
- Given: The initial context or precondition (system state before the scenario)