Forem: KRINO

When to Skip BDD

KRINO — Wed, 08 Apr 2026 12:00:00 +0000

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.*

BDD Test Cases from User Stories: 5 Steps and 12 Scenarios

KRINO — Thu, 02 Apr 2026 02:39:56 +0000

User stories set the destination. Test cases map every path, including the wrong ones.

In this post we walk through a 5-step BDD decomposition framework for turning a single user story into concrete Given/When/Then scenarios, with a complete worked coupon example. BDD (Behavior-Driven Development) structures tests as Given/When/Then scenarios that both stakeholders and tools like Cucumber or SpecFlow can understand.

Most teams write user stories in a format like:

As a checkout user,
I want to apply a discount coupon,
So that I pay less for my order.

Then they try to extract test cases directly from that sentence. The result is a handful of happy path scenarios and a nagging sense that something important was missed.

That instinct is right. This post explains why, and what to do about it.

Why User Stories Fail as Test Case Sources

User stories describe intent, not behavior. They answer why a feature exists, not what the system should do in every situation.

The coupon story above doesn't say:

What happens if the coupon is expired
What if the cart is below the minimum order value
Whether a coupon can be applied more than once
What if the coupon code is valid but belongs to a different user
What if the user removes an item after applying the coupon
What happens if the coupon service is temporarily unavailable

None of these are edge cases you invent. They're real scenarios that happen in production. They're just not in the user story because user stories aren't meant to capture them.

The gap between "the story" and "what needs testing" is where bugs live.

The 5-Step BDD Decomposition Framework

Don't try to extract test cases from the user story text directly. Use the story as a starting point for structured decomposition.

The framework in summary:

Identify the main scenario (the happy path)
Map every input and its valid boundaries
Add negative scenarios for each invalid input
Add boundary-condition scenarios at and around each threshold
Add error-handling and state-transition scenarios

Each step below.

Step 1: Identify the Main Scenario

What does the system do in the ideal case? This is your happy path, the scenario where everything works as intended.

Scenario: Valid coupon applies correct discount
  Given I have a cart with items totaling $50
  And I have a valid coupon "SAVE20" for 20% off
  When I apply the coupon
  Then the cart total should be $40
  And I should see "20% off applied"

This is what your product owner has in mind when they write the story. Necessary, but not close to enough.

Step 2: Map Every Input and Its Boundaries

Every input the user provides or the system receives has a valid range. List them explicitly.

Input	Valid Range	Boundary Cases
Coupon code	Alphanumeric, 4-20 chars	Empty, too short, too long, special chars
Expiry date	Today or future	Yesterday, today, tomorrow
Minimum cart value	Above minimum threshold (e.g., $30)	$29.99, $30.00, $30.01
Usage limit	0 - N uses per user	0, 1, max, max+1
User ownership	Owned by this user or global	Own coupon, other user's coupon, global

Each boundary is a potential test case. The edge of the valid range is where errors happen.

Step 3: Add Negative Scenarios

For each input, ask: what should the system do when this input is invalid, expired, or out of range? Each answer is a test case.

Scenario: Expired coupon is rejected with clear message
  Given I have a cart with items totaling $50
  And I have an expired coupon "OLD20"
  When I apply the coupon
  Then I should see the error "This coupon has expired"
  And the cart total should remain $50
  And no discount should be applied

Step 4: Add Boundary Conditions

Boundary conditions are the exact limits of valid input: the values right at, just below, and just above each threshold.

A coupon with a $30 minimum order value needs three scenarios:

Cart at $29.99 → coupon rejected
Cart at $30.00 → coupon accepted
Cart at $30.01 → coupon accepted

Scenario: Coupon rejected when cart is one cent below minimum
  Given I have a cart with items totaling $29.99
  And I have a valid coupon "SAVE20" with a $30 minimum
  When I apply the coupon
  Then I should see "Minimum order of $30 required"
  And the cart total should remain $29.99

Boundary conditions expose off-by-one errors, rounding bugs, and comparison operator mistakes (< vs <=). I've seen teams spend weeks debugging production issues that a single boundary test would have caught. The return on time invested is unusually high.

Step 5: Add Error Handling and State Scenarios

What happens if the coupon service is down? What if the user applies a coupon, then removes an item that drops the cart below the minimum?

State transitions (when valid inputs become invalid mid-session) are consistently under-tested. In most codebases I've worked on, they're not tested at all.

Scenario: Coupon auto-removed when cart drops below minimum
  Given I have a cart with items totaling $50
  And I have successfully applied coupon "SAVE20" with a $30 minimum
  When I remove items bringing the cart total to $25
  Then the coupon should be automatically removed
  And I should see "Coupon removed: cart below $30 minimum"
  And the cart total should be $25 with no discount

The Three Coverage Levels

Not every story needs exhaustive coverage immediately. A pragmatic approach uses three levels, chosen based on the risk profile of the feature.

Coverage Level	Scenarios	Focus	Use When
Quick	3 total	Happy path + obvious failures	Low-risk features, rapid prototyping, legacy system initial coverage
Standard	8 total	Adds boundaries & realistic edge cases	Most production features
Exhaustive	12 total	Adds security, concurrency, state transitions	Payment flows, authentication, data integrity, anything hard to roll back

Choosing the right level is a judgment call about risk, not a technical decision. Features that touch money, health data, or user permissions need Exhaustive. A blog post draft autosave feature probably needs Quick.

Worked Example: Coupon Application

User story: As a checkout user, I want to apply a discount coupon, so that I pay less for my order.

Quick Coverage (3 scenarios)

#	Scenario	Tests
1	Valid coupon applied	Correct discount shown, cart total updated
2	Invalid coupon code	Clear error message, cart unchanged
3	Expired coupon	Expiry-specific error message

Scenario: Valid coupon applies correct discount
  Given I have a cart with items totaling $50
  And I have a valid coupon "SAVE20" for 20% off
  When I apply the coupon
  Then the cart total should be $40
  And I should see "20% off applied"

Scenario: Invalid coupon code is rejected
  Given I have a cart with items totaling $50
  When I apply coupon "NOTREAL"
  Then I should see "Coupon not found"
  And the cart total should remain $50

Scenario: Expired coupon is rejected
  Given I have a cart with items totaling $50
  And I have an expired coupon "OLD20"
  When I apply the coupon
  Then I should see "This coupon has expired"
  And the cart total should remain $50

Standard Coverage Adds (5 more scenarios, 8 total)

#	Scenario	Tests
4	Cart below minimum order value	Minimum order error with threshold displayed
5	Single-use coupon applied twice	"Coupon already used" error
6	Coupon applied, then item removed below minimum	Coupon auto-removed, user notified
7	Cart at exactly minimum value	Coupon applies successfully
8	Cart $0.01 below minimum	Coupon not applicable

Scenario: Coupon rejected when cart is one cent below minimum
  Given I have a cart with items totaling $29.99
  And I have a valid coupon "SAVE20" with a $30 minimum order
  When I apply the coupon
  Then I should see "Minimum order of $30 required"
  And the cart total should remain $29.99

Scenarios 7-8 are the boundary pair for the minimum threshold. Testing both sides of the boundary catches < vs <= bugs that unit tests often miss.

Exhaustive Coverage Adds (4 more scenarios, 12 total)

#	Scenario	Tests
9	Coupon belonging to another user	"Coupon not found" (not "belongs to someone else")
10	Two simultaneous coupon applications	Only one applied, no double discount
11	Coupon code with SQL injection attempt	Sanitized and treated as invalid
12	Coupon applied, page refreshed	State persisted correctly

These deserve additional commentary.

Scenario 9: User Enumeration Prevention

At first glance, you might write the expected behavior as: "When I apply a coupon that belongs to another user, I see 'This coupon belongs to a different account.'"

That sounds helpful, but it leaks information. It confirms the coupon exists and is assigned to someone. An attacker can use this to enumerate valid coupon codes or confirm which users have coupons.

The correct behavior returns a generic "Coupon not found" message, identical to what you'd see for a coupon that doesn't exist at all.

Scenario: Coupon belonging to another user returns generic not-found
  Given I have a cart with items totaling $50
  And a coupon "PRIVATE10" exists but belongs to another user
  When I apply coupon "PRIVATE10"
  Then I should see "Coupon not found"
  And the cart total should remain $50

Scenario 10: Race Condition / Double Discount

If a user opens two tabs and clicks "Apply Coupon" simultaneously, what happens? Without explicit concurrency handling, you can end up with double discounts or corrupted cart state. I've seen promotions lose thousands of dollars to this exact bug during flash sales.

Scenario 11: Input Sanitization

The coupon code field accepts user input. That input will hit your database. Malicious input should be sanitized and rejected as "invalid code," not cause errors or, worse, execute.

Scenario 12: State Persistence

If a user applies a coupon then refreshes the page, is the coupon still applied? This tests session or database persistence. It sounds obvious, but I've seen carts silently drop discounts on refresh because the coupon was stored client-side only.

Common Mistakes

Four mistakes I see repeatedly in BDD scenarios.

Mistake 1: Testing the Implementation, Not the Behavior

BDD scenarios should describe what the system does from a user's perspective, not how it does it internally.

Bad:

Scenario: Click apply button sends API request
  Given I am on the cart page
  When I click the "Apply Coupon" button
  Then a POST request is sent to /api/v1/coupons/apply

Good:

Scenario: Valid coupon applies correct discount
  Given I have a cart with items totaling $50
  When I apply coupon "SAVE20"
  Then my cart total should be $40

The bad version tests implementation details. The good version tests behavior. Only the second survives a refactor.

Mistake 2: Skipping Boundary Conditions

Teams often test "valid" and "invalid" but miss the exact threshold. If the minimum order is $30, test $29.99, $30.00, and $30.01 — not just "$20" and "$50."

Mistake 3: Coupling to UI Elements

Scenarios that say "When the user clicks the Apply Coupon button" couple your test cases to your UI. Describe actions at the domain level: "When the user applies coupon SAVE20."

Mistake 4: One Huge Scenario Instead of Multiple Focused Ones

A scenario with twelve steps and three outcomes is testing three things at once. When it fails, you don't know which of the three things broke. One behavior per scenario.

Where AI Fits: Honestly

AI test case generation is useful but uneven. Worth being specific about where it helps and where it doesn't.

AI handles well:

Volume. Given a well-structured user story, AI can generate a complete scenario set in seconds rather than the hour it might take manually.
Consistency. AI doesn't forget null inputs or boundary values — the inputs you'd normally catch on the thirtieth scenario of the day when you're no longer paying attention.
Format compliance. Gherkin syntax is strict, and AI follows it reliably.
Coverage breadth. AI applies the decomposition systematically across every input. It won't skip Step 4 because it's Friday afternoon.

AI handles poorly:

Domain-specific rules. Your business has constraints that aren't in the user story: user enumeration risks, regional compliance requirements, product-specific logic. AI doesn't know these unless you tell it explicitly.
Organizational context. Which test cases already exist? Which are covered by integration tests at a lower level? AI doesn't have this information and will generate duplication.
Coverage level judgment. Deciding whether a feature needs Quick, Standard, or Exhaustive coverage is a risk assessment about your system, your users, and your rollback capability. That's a human call.

What actually works: let AI handle Steps 2-5 at the coverage level you choose, then review and add the domain constraints it can't know. You get AI's consistency with your context.

Summary

The gap between user stories and test cases is where bugs live. A structured decomposition approach closes that gap:

Identify the main scenario — the happy path
Map every input and its boundaries — the raw material for edge cases
Add negative scenarios — what happens when inputs are invalid
Add boundary conditions — the exact thresholds where errors hide
Add error handling and state transitions — the scenarios that survive production

Choose your coverage level based on risk: Quick for low-stakes features, Standard for most production work, Exhaustive for anything involving money, security, or data integrity.

This is part of the Practical Test Design series. I'm building KRINO Dokim, a tool that applies this 5-step framework automatically — you choose the coverage level, it generates the scenarios, and you review with full visibility into why each scenario was created. If you work with user stories and BDD, I'd genuinely appreciate your feedback on the approach.

What coverage level does your team default to? Have you run into the user enumeration trap (Scenario 9)? I'd love to hear in the comments.