Definition
- Given-When-Then – Given sets the precondition, When describes the action, Then states the expected outcome.
- Plain language – Feature files are written in natural language that business, testers, and developers all share.
- Step definitions – Glue code that maps each Given/When/Then to actual automation code.
- Tools – Cucumber (Java/JS/Ruby), SpecFlow (.NET), Behave (Python).
- Living documentation – Feature files are both readable specifications and executable tests.
- Best for – Complex business rules where stakeholder alignment on behavior is critical.
At the National Bank of India, instead of the business team, testers, and developers arguing over a vague requirement, they all sit together and write the behavior in simple sentences everyone understands: "Given Rajesh is logged in, When he transfers fifty thousand rupees to Priya, Then his balance decreases by fifty thousand and Priya's increases by fifty thousand." This reads like plain English, so a manager who cannot read code can confirm it is correct. Behind the scenes, an engineer connects each sentence to a bit of automation, so the same plain-English scenario actually runs as a test. BDD is about getting everyone to agree on behavior in words first, then making those words executable.
Understanding the Concepts
What is BDD?
BDD, Behavior-Driven Development, describes system behavior in plain language using Given-When-Then format that business, testers, and developers all share.
# Feature file: transfer.feature
Feature: Fund Transfer
Scenario: Successful transfer between accounts
Given Rajesh has a savings account ACC-001 with balance 50000 INR
And Priya has a savings account ACC-002 with balance 10000 INR
When Rajesh transfers 5000 INR to ACC-002
Then Rajesh's balance should be 45000 INR
And Priya's balance should be 15000 INR
And a transaction record should be created
What is the Given-When-Then format?
Given sets the precondition, When describes the action, Then states the expected outcome.
- Given : The initial context or precondition. "Given Rajesh has an account with 50000 INR."
- When : The action or event that triggers behavior. "When he transfers 5000 INR."
- Then : The expected outcome to verify. "Then his balance should be 45000 INR."
- And/But : Additional conditions within any section. "And a transaction record should be created."
Scenario: Insufficient balance prevents transfer
Given Rajesh has a savings account with balance 1000 INR
When Rajesh attempts to transfer 5000 INR to ACC-002
Then the transfer should be rejected
And the error message should be "Insufficient balance"
And Rajesh's balance should remain 1000 INR
What are step definitions?
Step definitions are the glue code that maps each Given/When/Then to actual test automation.
// StepDefinitions.java (Cucumber + Java)
package com.bank.steps;
import io.cucumber.java.en.*;
import java.math.BigDecimal;
import static org.junit.jupiter.api.Assertions.*;
public class TransferSteps {
private AccountService accountService = new AccountService();
private TransferResult result;
@Given("Rajesh has a savings account {string} with balance {int} INR")
public void rajeshHasAccount(String accountId, int balance) {
accountService.createAccount(accountId,
new BigDecimal(balance), "Rajesh");
}
@When("Rajesh transfers {int} INR to {string}")
public void rajeshTransfers(int amount, String toAccount) {
result = accountService.transfer(
"ACC-001", toAccount, new BigDecimal(amount));
}
@Then("Rajesh's balance should be {int} INR")
public void verifyBalance(int expected) {
BigDecimal actual = accountService.getBalance("ACC-001");
assertEquals(new BigDecimal(expected), actual);
}
}
What tools implement BDD?
| Tool | Language | Feature |
|---|---|---|
| Cucumber | Java, JS, Ruby | Most popular, multi-language |
| SpecFlow | C# / .NET | Cucumber for .NET |
| Behave | Python | Python BDD framework |
| Playwright BDD | TypeScript | BDD for browser testing |
# Run Cucumber tests
mvn test -Dcucumber.features=src/test/resources/features
# Run with tags
mvn test -Dcucumber.filter.tags="@transfer"
What is a feature file?
A feature file is living documentation: readable by non-technical stakeholders and executable as tests.
@transfer @critical
Feature: Fund Transfer
As a bank customer
I want to transfer money between accounts
So that I can manage my finances
Background:
Given the National Bank of India system is running
And Rajesh is logged in as a customer
Scenario Outline: Transfer various amounts
Given Rajesh has a balance of <initial> INR
When he transfers <amount> INR
Then his balance should be <final> INR
Examples:
| initial | amount | final |
| 50000 | 5000 | 45000 |
| 50000 | 50000 | 0 |
| 1000 | 500 | 500 |
How do BDD and manual testing relate?
BDD scenarios can serve as both automated tests and manual test case descriptions, bridging the gap.
Business requirement
│
▼
Feature file (Given-When-Then)
│
├──> Automated test (step definitions)
│
└──> Manual test guide (readable by QA)
When is BDD most valuable?
BDD is most valuable when business rules are complex and stakeholder alignment on behavior is critical.
High BDD value:
- Loan approval rules (complex conditions)
- Regulatory compliance scenarios
- Multi-step workflows with business logic
Lower BDD value:
- Simple CRUD operations
- Technical infrastructure tests
- Performance tests
What are common interview follow-up questions?
- "Who writes the feature files?" Ideally the product owner, QA, and developer together in a Three Amigos session.
- "Can BDD replace unit tests?" No. BDD tests behavior at the acceptance level. Unit tests are still needed for internal logic.
- "What is the Three Amigos practice?" A short session where the product owner, developer, and tester agree on the scenarios before development starts.
Key Takeaway
Behavior-Driven Development is a collaborative practice where I describe the expected behavior of a system in plain, structured natural language using the Given-When-Then format, so that business, testing, and development all share one unambiguous specification. Given establishes the starting context, When describes the action, and Then states the expected outcome, and I can chain conditions with And and But. For example: Given Rajesh is logged in with a balance of one million, When he transfers fifty thousand to Priya, Then his balance is nine hundred fifty thousand and Priya's is three hundred thousand. Because it reads like plain English, a product owner or auditor who cannot read code can validate it.
The practice usually starts with a conversation among the three perspectives, often called the three amigos, who write the scenarios together as concrete examples, which removes ambiguity before any code is written. Those plain-language scenarios become executable through step definitions: each Given, When, and Then line is bound to a method that performs the action or assertion, so the same artifact is both the human-readable specification and the automated acceptance test, which keeps documentation and tests in sync. In Java the common tools are Cucumber, which uses the Gherkin plain-text language and matches each step to a step-definition method, and JBehave, which follows the same Given-When-Then philosophy with its own story format.
The nuances I stress are that BDD's real value is the collaboration and the shared ubiquitous language, not just the Gherkin syntax, so teams that adopt the keywords without the conversation gain little. I write scenarios at the level of business behavior rather than UI mechanics so they stay readable and stable, and I hide the technical detail in the step definitions. I am also honest that there is a maintenance cost to the extra Gherkin and binding layer, so it is worth it when non-technical stakeholders genuinely participate and acceptance criteria benefit from being explicit, but plain unit tests are simpler for purely developer-facing logic. At the National Bank of India I used Cucumber for complex business rules like transfer eligibility and fee calculation, where getting business, testing, and development to agree precisely on behavior in language auditors could read had real value. Being able to explain the Given-When-Then structure, the binding to step definitions, the tools, and above all the collaboration behind it is what shows an interviewer I understand BDD as a shared-understanding practice rather than just a test syntax.
Remember one sentence: BDD describes behavior in plain Given-When-Then language that business and technical people share, then binds it to executable automation.
---
Visual Overview
BDD Given-When-Then Flow
─────────────────────────
Feature File (plain language)
┌──────────────────────────────┐
│ Feature: Fund Transfer │
│ │
│ Scenario: Successful transfer│
│ Given Rajesh has 50000 INR │
│ When he transfers 5000 │
│ Then his balance is 45000 │
└──────────────┬───────────────┘
│ bound to
┌──────────────▼───────────────┐
│ Step Definitions (code) │
│ │
│ @Given Rajesh has {amount} │
│ -> seed account │
│ @When he transfers {amount} │
│ -> call transfer API │
│ @Then balance is {amount} │
│ -> assert balance │
└──────────────────────────────┘