Behavior-Driven Development (BDD): Gherkin and Cucumber

What is behavior-driven development?

Behavior-driven development, or BDD, is a way of building software that describes a system through the behavior people expect from it. Instead of starting with technical test cases, the team starts with conversations about business outcomes, user actions, rules and examples.

Dan North is credited with the idea in the mid-2000s, as an evolution of test-driven development. The aim was to make conversations about software easier to follow by focusing on behavior: in this situation, when someone does this, that should happen. A good BDD scenario can be read by a non-technical stakeholder, used by a developer and checked by a tester.

The three BDD practices: discovery, formulation and automation

Discovery is the conversation. The people who understand the need, build the feature and test it walk through concrete examples before anything is built, to surface uncertainty while it is cheap to discuss. For an appointment booking feature: can customers book outside business hours, does staff have to approve, and what happens if the slot is taken?
Formulation writes the agreed examples in a structured, plain-language format, usually Gherkin, specific enough to remove ambiguity and readable from the outside.
Automation connects those scenarios to code that runs them as tests, so the team can confirm at any time that the behavior still works.

Automation should not replace the first two. Writing test scripts in Given/When/Then form without the conversation is a BDD-style format, not BDD.

How Given/When/Then scenarios work

Given sets the starting situation, When describes the action or event, and Then states the expected result. Each scenario covers one behavior. An example for a small business booking page:

Scenario: Customer books an available appointment
Given a therapist has an open appointment at 2:00 p.m. on Friday
And the customer is on the booking page
When the customer chooses the 2:00 p.m. Friday slot and confirms
Then the appointment is reserved for that customer
And the customer receives a booking confirmation

Anyone can check whether that behavior is right without reading code. If the business later decides staff must approve bookings first, the scenario changes to say so. A scenario that tries to cover booking, payment, cancellation and email all at once becomes hard to read and hard to maintain.

Gherkin syntax basics

Gherkin is the plain-text format most BDD tools read. Its main keywords:

Feature names the feature and can explain its business purpose.
Rule groups scenarios under one business rule.
Scenario describes one example of behavior.
Given, When, Then set the context, action and result; And and But add steps.
Background holds setup shared by several scenarios in a file.
Scenario Outline with Examples runs one scenario with a table of different values.

The point is not to make requirements look formal. It is to make examples consistent and testable. An invoice approval feature, for instance, might have one scenario each for an invoice below the approval threshold, one above it, and one missing required details.

How Cucumber runs BDD scenarios as tests

Cucumber is a common tool for running BDD scenarios. It reads .feature files written in Gherkin and matches each step to step-definition code written by the team:

The team writes a scenario in a .feature file.
Cucumber finds the matching step definition for each line.
Each step definition does something: opens a page, creates test data, calls an interface or checks a result.
Cucumber reports which scenarios passed and which failed.
The team fixes the code, the test setup or the scenario.

Other tools support the same workflow in different programming languages; the practice matters more than the tool. Automation also has a cost: step definitions need design, test data needs managing, and tests that drive the screen can be slow and fragile. Many teams automate only the scenarios that protect important business behavior.

BDD vs TDD

Test-driven development (TDD) is a developer practice: write a failing test, write just enough code to pass it, then tidy the code while the tests stay green. Both encourage thinking before building and both use tests as feedback. The difference is focus and audience:

Focus: BDD starts from business behavior and shared examples; TDD starts from the design of a unit of code.
Audience: BDD involves product owners, testers and developers; TDD is mostly for developers.
Format: BDD uses Gherkin scenarios and acceptance examples; TDD uses unit tests in the programming language.
Best use: BDD clarifies requirements and acceptance criteria; TDD helps design reliable code in small steps.

They work well together: agree on how an invoice approval workflow should behave with BDD, then build the approval rules with TDD.

When BDD helps, and when it is overkill

BDD tends to pay off when requirements are easy to misunderstand or full of exceptions, when business, testing and development people need a shared language, when acceptance criteria are vague, when building the wrong thing would be costly, or when re-testing key workflows by hand has become a chore.

It is usually unnecessary for very small changes, internal technical cleanup, throwaway demos or work where the behavior is already obvious, and it stalls if the business people are not available for discovery. A useful test: if writing a scenario does not clarify anything, guide a decision or protect important behavior, use something lighter.

Common BDD mistakes

Starting with tools instead of conversations. Installing Cucumber does not create shared understanding.
Writing technical scenarios. Database tables, page selectors and method names do not belong in a scenario.
Long end-to-end scripts. One scenario per behavior is easier to read and to debug.
Vague outcomes. "Then the invoice is processed correctly" should say what the user sees or what status changes.
Automating every example. Some examples are for discussion only.
Letting scenarios go stale. When a rule changes, the scenario changes with it.
Leaving testers out of discovery. They spot missing cases and hidden assumptions early.

How to start BDD on one feature

Pick one feature with visible behavior and some uncertainty, such as booking, invoice approval, password reset or order status.
Bring together someone who knows the business need, someone who will build it and someone who will test it.
Talk through examples: the normal case, missing information and the exceptions that matter.
Write two or three short Gherkin scenarios, one behavior each.
Check that a business stakeholder can read them; rewrite them if not.
Automate the ones that protect important behavior, with Cucumber or a similar tool.
Update the scenarios as part of every change to the feature.

Where ASL fits

ASL's custom software development work rests on the same idea as BDD: agree on the first release and its acceptance examples before building, choose a bounded release with acceptance checks you can observe, and review the working software with representative, approved data. You do not need to know Gherkin to take part; you need to be able to say what should happen in each situation.

Frequently asked questions

What is BDD in simple terms?

Behavior-driven development is a way of building software where the team first agrees on concrete examples of what the software should do, writes them as Given/When/Then scenarios, and then uses those scenarios to guide and test the code.

Who created behavior-driven development?

Dan North is credited with introducing BDD in the mid-2000s as an evolution of test-driven development.

What is the difference between Gherkin and Cucumber?

Gherkin is the plain-text format for writing scenarios with keywords such as Feature, Scenario, Given, When and Then. Cucumber is a tool that reads Gherkin files and runs each step as an automated test.

Is BDD the same as TDD?

No. TDD is a developer practice focused on designing code through unit tests. BDD focuses on business behavior and shared examples that business people, testers and developers can all read. Teams often use both.

Do I need Cucumber to do BDD?

No. The conversations and clear examples are the core of BDD. Cucumber or a similar tool adds automation, and many teams automate only their most important scenarios.

Related guides

Explore the complete product

Read features, current access and limitations

Behavior-Driven Development (BDD): How It Works, Gherkin and Cucumber