BDD vs TDD: Key Differences for QA and Developers

A product owner approved a story saying that an expired subscription could be renewed. The developer used test-driven development to produce a clean renew() method with full branch coverage. QA later found that customers in a grace period were charged twice because product, engineering, and billing had interpreted “expired” differently. The code behaved exactly as its unit tests specified, but the team had never agreed on the business example.

The reverse failure is just as common. A team writes polished Given-When-Then scenarios for every story but implements them after the feature through slow browser steps. The scenarios create documentation and automation work, yet they do little to guide code design.

BDD and TDD solve related problems at different feedback boundaries. TDD drives the design of code through rapid executable checks. BDD uses concrete examples to discover and communicate observable behavior. A mature team can use both without forcing either technique to do the other’s job.

Separate the two feedback loops

Test-driven development follows a small implementation loop:

1. Write one failing test for the next behavior.
2. Write the smallest code that makes it pass.
3. Refactor tests and production code while keeping the suite green.
4. Repeat with the next example.

The first failure is important. It proves that the test can detect the missing behavior and helps prevent a false-positive check. The small step limits the number of possible causes when the test fails. Refactoring then improves the design under a safety net.

Behavior-driven development begins earlier and at a broader boundary. People with product, testing, and technical perspectives discuss a capability using examples. They identify business rules, unanswered questions, and observable outcomes. Selected examples may become executable specifications, but automation is not the definition of BDD.

A practical BDD discovery loop looks like this:

1. Describe the capability and the user or business outcome.
2. Explore rules with concrete examples and counterexamples.
3. Resolve language, scope, and edge-case questions.
4. Record the examples in a shared form.
5. Implement the behavior, often using TDD at the code level.
6. Verify the observable examples and revise the model when learning occurs.

TDD asks, “What should this unit of code do next?” BDD asks, “What behavior should the product exhibit, and what example would show it?” Both rely on examples, but their audiences and scopes differ.

Compare BDD and TDD by engineering purpose

The techniques are not competing test levels. A BDD example can be automated through an API, component, or browser. A TDD loop can drive a pure function or a service adapter. Tool choice does not establish the practice. Writing Jest tests after implementation is not test-driven development, and installing Cucumber does not create behavior-driven collaboration.

Use TDD to shape a small, reliable design

Suppose the agreed rule is: an inventory reservation succeeds only when enough stock remains, and a rejected reservation must not change stock.

Start with one missing behavior. The following example uses TypeScript and Vitest, but the loop applies in other languages.

import { describe, expect, test } from "vitest";
import { Inventory } from "./inventory";

describe("Inventory.reserve", () => {
  test("reduces available stock after a valid reservation", () => {
    const inventory = new Inventory({ "FIELD-KIT": 3 });

    const result = inventory.reserve("FIELD-KIT", 2);

    expect(result).toEqual({ accepted: true, remaining: 1 });
    expect(inventory.available("FIELD-KIT")).toBe(1);
  });

  test("leaves stock unchanged when the request is too large", () => {
    const inventory = new Inventory({ "FIELD-KIT": 1 });

    const result = inventory.reserve("FIELD-KIT", 2);

    expect(result).toEqual({
      accepted: false,
      reason: "insufficient-stock",
    });
    expect(inventory.available("FIELD-KIT")).toBe(1);
  });
});

Write the first test, observe the expected failure, implement enough behavior, and refactor before adding the rejection case. Do not write a dozen speculative tests and then implement everything at once. Large red phases weaken the diagnostic value of the loop.

A minimal implementation might expose only the operations the behavior needs:

type Reservation =
  | { accepted: true; remaining: number }
  | { accepted: false; reason: "insufficient-stock" };

export class Inventory {
  constructor(private readonly stock: Record<string, number>) {}

  reserve(sku: string, quantity: number): Reservation {
    const available = this.available(sku);
    if (quantity > available) {
      return { accepted: false, reason: "insufficient-stock" };
    }

    this.stock[sku] = available - quantity;
    return { accepted: true, remaining: this.stock[sku] };
  }

  available(sku: string): number {
    return this.stock[sku] ?? 0;
  }
}

The tests encouraged a narrow API and an explicit result type. They do not prove concurrent reservations are atomic or data is persisted. Those risks need integration tests against the real storage boundary. TDD improves design inside the chosen boundary; it does not make the boundary complete.

Avoid excessive mocking. If every collaborator is mocked and tests assert call order, the suite may preserve the current implementation instead of behavior. Prefer real value objects and small in-memory collaborators. Mock network, time, random generation, and expensive infrastructure only at intentional seams.

Use BDD to discover rules before automation

The stock rule sounds simple until the team explores examples:

• What happens when two customers request the last unit?
• Can quantity be zero or negative?
• Is stock reserved before or after payment authorization?
• How long does a reservation live?
• Can staff oversell?
• Which message should a customer see?

A short example workshop can expose these questions before code and test plans diverge. Use a capability, rules, examples, and open questions rather than beginning with step syntax.

If the team chooses Gherkin, write scenarios around outcomes:

Feature: Reserve stock during checkout

  Rule: A customer cannot reserve more stock than is available

    Scenario: The requested quantity is available
      Given 3 units of "FIELD-KIT" are available
      When a customer reserves 2 units
      Then the reservation is accepted
      And 1 unit remains available

    Scenario: The requested quantity exceeds available stock
      Given 1 unit of "FIELD-KIT" is available
      When a customer reserves 2 units
      Then the reservation is rejected as "insufficient stock"
      And 1 unit remains available

These scenarios clarify a domain rule and its externally visible results. They avoid page names, button labels, database tables, and internal method calls. The language can survive a redesign of the checkout screen.

Not every discussed example should become a feature-file scenario. Keep examples that define important rules, prevent a likely misunderstanding, or support traceable acceptance. Detailed permutations may be clearer as parameterized code tests. Exploratory notes and unanswered questions can remain in the story or decision record.

Turn specifications into maintainable checks

Executable BDD adds a mapping from domain phrases to automation. Keep that mapping thin. A step should translate parameters and call an application-facing driver, not contain the whole implementation.

When(
  "a customer reserves {int} units",
  async function (this: StockWorld, quantity: number) {
    this.reservation = await this.stockDriver.reserve(
      this.sku,
      quantity,
    );
  },
);

Then(
  "the reservation is rejected as {string}",
  function (this: StockWorld, reason: string) {
    expect(this.reservation).toEqual({
      accepted: false,
      reason: reason.replace(" ", "-"),
    });
  },
);

The stockDriver may call an API or a service component. The scenario should not care which transport is used. This makes it possible to run acceptance checks below the browser when the user interface is not part of the rule.

Control scenario state explicitly. Create unique stock records, store identifiers in a typed world object, and clean up through supported hooks. Avoid global variables and scenarios that rely on execution order. Report the input example and returned domain result on failure.

Step reuse should follow shared meaning. Do not create vague steps such as When I process the request merely to reuse code across unrelated capabilities. Conversely, do not add five phrases that mean the same thing. A small domain vocabulary reduces ambiguity and duplicate step definitions.

Combine BDD and TDD on one repository change

For a subscription-renewal story, the workflow can use both techniques without duplication.

During refinement, product, QA, and engineering agree on examples for active, grace-period, expired, and canceled subscriptions. They establish that a grace-period renewal extends the existing entitlement and must not create a second charge. Those examples define acceptance at the service boundary.

During implementation, the developer selects the grace-period rule and begins a TDD loop around a RenewalPolicy. Small tests drive date boundaries, entitlement extension, and the command sent to billing. An integration test verifies idempotency against the real persistence mechanism. The developer runs these checks locally on every small change.

The executable BDD example then calls the renewal API with a prepared subscription and verifies the observable entitlement and charge result. It does not repeat every date boundary from the unit suite. A single browser smoke check may confirm that a customer can initiate renewal, but the billing combinations remain below the UI.

A repository could reflect those boundaries directly:

src/
  renewal/
    renewal-policy.ts
    renewal-service.ts
    renewal-policy.test.ts
tests/
  integration/
    renewal-idempotency.test.ts
  acceptance/
    features/subscription-renewal.feature
    steps/subscription-renewal.steps.ts
    drivers/subscription-driver.ts
  smoke/
    customer-renewal.spec.ts

This structure is not mandatory. The important point is that each check owns a distinct risk. TDD tests protect internal rules and design. Acceptance examples protect agreed behavior. Integration and smoke checks protect real boundaries.

Know where each practice fails

TDD can become test-first bureaucracy when a team writes tests without using feedback to improve design. Warning signs include giant setup fixtures, mocks for every method, assertions on private state, and tests that break during harmless refactoring. Revisit the unit boundary, reduce construction cost, and assert public outcomes.

TDD is also awkward during uncertain spikes. It can be reasonable to explore an API, discard the prototype, and restart with tests once the shape is understood. Keeping untested exploratory code as production code is the risk, not exploration itself.

BDD fails when feature files are handed from analysts to developers as fixed requirements. Behavior discovery needs conversation and examples, not a new document format. It also fails when hundreds of scenarios restate every UI interaction. Review whether each scenario captures a business rule that someone outside automation values.

Do not use BDD reports as the only product documentation. Executable examples cover selected behavior, not every operational constraint or design decision. Do not use TDD coverage as proof that customer workflows work. Both techniques leave infrastructure, accessibility, security, performance, and exploratory risks that require other forms of testing.

Verify the practices through observable evidence

For TDD, review the development loop as well as the final files. A good pull request shows small focused tests, production interfaces shaped around behavior, and no unnecessary test-only access to internals. Temporarily revert or mutate the new implementation and confirm the tests fail for the intended reason. Run tests in random order where the runner supports it to reveal shared state.

For BDD, verify that the examples were reviewed before or during implementation. Ask each participant to explain the rule in the same terms. Execute scenarios at the lowest faithful boundary and intentionally break a rule to confirm the failure names the business outcome. Search the step catalog for ambiguous or duplicate phrases.

Use a compact review checklist:

• Does each example identify a meaningful outcome?
• Are boundary values and counterexamples represented at the right layer?
• Did the new test fail before the behavior existed?
• Can production code be refactored without rewriting behavioral assertions?
• Are acceptance drivers isolated from Gherkin wording?
• Does failure output distinguish a rule defect from environment setup?
• Is any browser scenario carrying combinations that belong in code tests?

The choice is rarely BDD versus TDD for an entire team. Use BDD where shared examples prevent expensive misunderstandings. Use TDD where rapid tests can guide a cohesive implementation. Connect them through the same domain language, and let each feedback loop protect the boundary it can explain best.