BDD is useful, but it is not free.
Every Given/When/Then scenario takes time to discuss, write, review, maintain, and explain. If teams use BDD everywhere by default, a useful collaboration tool can turn into process overhead. The real question is not whether BDD is good. The real question is whether BDD is worth the cost for a particular feature.
BDD is strongest when the problem is ambiguous, risky, or easy to misunderstand. It is weakest when the work is small, obvious, or unlikely to benefit from formal examples.
What BDD Is For
BDD exists to solve a communication problem, specifically the misalignment between what stakeholders want and what developers build.
The Given/When/Then format forces teams to describe behavior in concrete, testable terms before code is written. This makes BDD especially useful when multiple people need to agree on what "correct" means.
BDD works best when:
- Requirements are vague or open to interpretation.
- Multiple roles or systems interact.
- Business rules have edge cases.
- The feature will live for a long time.
- Mistakes are expensive to fix.
In those situations, the act of writing scenarios is part of the value. The conversation exposes assumptions, and the examples force the team to get specific.
What BDD Actually Costs
Before deciding when to skip BDD, it helps to be honest about what it costs. Every Gherkin scenario carries overhead.
Writing time. A well-structured scenario takes time to write, especially when boundaries and edge cases need to be covered.
Maintenance. When requirements change, every affected scenario needs updating.
Glue code. If Gherkin is automated, each step definition needs implementation and upkeep.
Review overhead. Scenarios only matter if someone actually reads them.
None of this means BDD is bad. It means BDD is an investment with a specific return, i.e., shared understanding across roles. If that return does not apply, the investment does not pay off.
A Simple Decision Rule
The following rule captures when BDD earns its cost:
Use BDD when the cost of misunderstanding is higher than the cost of writing scenarios.
To this end, a practical filter emerges. If the feature is risky, use BDD. If it crosses team boundaries, use BDD. If it is tiny, obvious, and low-risk, forcing BDD just to be consistent adds ceremony without benefit.
BDD should match the risk, not the habit.
When to Skip BDD
The decision rule points to specific cases where BDD is not worth the overhead:
- A small internal utility.
- A one-off admin fix.
- A low-risk refactor with no behavior change.
- A throwaway prototype.
- Algorithmic or mathematical code.
For algorithmic code especially, a focused unit test is clearer than a business-readable scenario:
@pytest.mark.parametrize("principal,rate,years,expected", [
(1000, 0.05, 1, 1050.00),
(1000, 0.05, 10, 1628.89),
(0, 0.05, 10, 0.00),
])
def test_compound_interest(principal, rate, years, expected):
assert round(compound(principal, rate, years), 2) == expected
No product owner needs to read this test. It belongs in a unit test file, not a .feature file. For features that do belong in BDD, the 5-step decomposition framework shows how to structure scenarios.
Quick Reference
The obvious cases are easy. The borderline cases are where this table helps:
| Feature | Stakeholder cares? | Expensive if wrong? | Verdict |
|---|---|---|---|
| Password reset | Yes | Yes | BDD |
| Audit logging | Yes (compliance) | Yes | BDD |
| CSV export (admin only) | Maybe | Low | Integration test |
| Retry handler | No | Low | Unit test |
| Feature flag rollout | Maybe | Maybe | Depends on blast radius |
A useful test: would a product owner find this scenario useful if shown to them? If yes, BDD is probably a good fit. If no, a simpler test is likely sufficient.
What "Skip BDD" Does Not Mean
Skipping BDD does not mean skipping thinking.
It does not mean no review, no acceptance criteria, no regression awareness, and no understanding of the user impact. It only means the full scenario-writing overhead is not required every time.
A lightweight test note can be enough for small work. A verbal conversation can be enough for a simple fix if the team already shares context. The point is to use the lightest method that still creates confidence.
When BDD Cannot Be Skipped
BDD is absolutely worth the overhead when the cost of getting the behavior wrong is high and multiple roles need to agree on what "correct" means.
BDD earns its keep when teams are working on:
- Payment flows.
- Pricing or discount logic.
- Authentication and permissions.
- Compliance and regulatory behavior.
- Multi-step workflows.
- Cross-team integrations.
- Irreversible operations like deletions or migrations.
- Features where business rules live in someone's head instead of the code.
These are the features where a scenario is not just documentation. It is a shared agreement about behavior.
Scenario: Suspended user cannot complete checkout
Given I have items in my cart totaling $50
And my account status is "suspended"
When I attempt to complete checkout
Then the checkout should be blocked
And I should see "Your account is suspended. Contact support."
And no payment should be processed
This scenario crosses domains (account status affects checkout), involves multiple stakeholders (support, billing, product), and prevents a high-cost failure (charging a suspended user). A unit test cannot capture this. A conversation without a written example will miss the edge.
How AI Changes the Equation
AI reduces the cost of writing scenarios, but it does not change the decision of whether BDD is appropriate.
The core questions remain. Does this behavior need stakeholder agreement? Is the cost of misunderstanding high? Will the scenarios be read and maintained?
AI can generate scenarios quickly. Features that were not worth thirty minutes of manual scenario writing may now be worth a thirty-second generation pass to surface edge cases. However, AI cannot decide whether BDD is the right layer for the problem. This is why the "when to skip BDD" question matters even more when generation is fast.
Summary
BDD solves a communication problem. When that problem does not exist, BDD becomes ceremony.
Skip BDD for prototypes, low-risk internal changes, implementation details, and algorithmic code. Use BDD for stakeholder alignment problems, high-risk behavior, cross-team workflows, and anything expensive to get wrong.
The discipline is not writing more BDD. The discipline is writing BDD where it earns its cost.
This post is part of the **Practical Test Design* series. Previously: BDD Test Cases from User Stories: 5 Steps and 12 Scenarios.*
Top comments (0)