Principles of BDD | Sean Dinwiddie's Webmastery

Updated October 4, 2026· Development

Behavior-driven development (BDD) runs on eight principles, and every one keeps the work facing the same way: toward the behavior of the software as its users see it. Each comes with the habit that shows it in practice.

People and words

User-centric perspective: Every scenario is told from where a user stands, with an outcome that user would notice. A scenario that can only be told from the database’s side, a row inserted or a flag set, means the need behind it hasn’t been found yet, and the conversation goes back to the people who use the result.
Collaboration: Behavior is settled between the people who know the business and the people who build the software. On a Sean Dinwiddie’s Webmastery job, that is the owner, with the staff who use the result, and the webmaster, reading the scenarios together before work starts; what they settle goes into the written scope.
Common language: Each thing keeps one name, the owner’s, from the written scope through the scenario to the action and the test. Where a name has to change, the owner and the webmaster agree on the new one, and it changes everywhere at once, so no reader has to translate.

Behavior as scenarios

Behavior specifications: Behavior specifications say how the software should behave in specific situations, usually in Given-When-Then form. Each scenario turns one expected behavior into a check a test can run.
Given-When-Then scenarios: Each scenario sets the context (Given), names one event (When) and checks the outcome (Then); Given-When-Then (Gherkin) syntax in BDD writes them out keyword by keyword.

Checks that keep running

Continuous feedback: A scenario is read before work starts and run on every change after it, so the owner hears about a misunderstanding while it is still a sentence, and the webmaster hears about a regression the moment it happens.
Automation: A scenario is finished when it runs as a test on every change and fails under its own name when the behavior breaks. The team runs scenarios both ways, as cucumber-js steps or as scenario-named tests in Vitest or Hspec, and BDD testing framework runs one scenario each way.
Integration with development practices: BDD rarely works alone. It pairs with practices such as test-driven development (TDD), which complements it by writing the tests first and letting them drive development. The lecture Functional Composition ends the same way at the smallest scale, stating the laws its functions must keep as tests.

Put feedback and automation on a timeline and a scenario earns its keep twice:

One scenario, two kinds of feedback, with time running left to right. Before work starts, the owner reads it (outlined in violet) and a misunderstanding costs a sentence; after, its test runs on every change and a regression shows the moment it happens.

The rule behind the examples. Each principle shows up as something a reader can check in one scenario. Take the checkout from Creating BDD scenarios for real-world cases:

Feature: Checkout

  Scenario: Placing the order
    Given Ada's cart holds "Widget A" at $25
    And she has chosen an address and a card
    When she places the order
    Then the order is recorded at $25
    And her cart is empty

Read it once for each principle:

The user’s perspective: Ada is a person with an outcome she would notice, never a row in a table.
Behavior as a scenario: one context (her cart, her address and her card), one event (she places the order) and outcomes a test can check.
Collaboration, in a common language: the owner reads it in the written scope before work starts and can say where it’s wrong.
One name for each thing: its words carry into the code as names, such as placeOrder, and its Then into a test that checks the cart’s lines are empty, so the owner’s word and the test’s word stay the same.
Automation and continuous feedback: it runs on every change as a test named for it, and a failure names the behavior that broke.
Integration with TDD: underneath it, unit tests pin the pure functions it rests on, such as the order’s total, which the API’s pure core works out from today’s prices (validateOrder in Module 4): behavior-driven on the outside, test-driven within.

A principle that shows up in no scenario is only a slogan, and a group review, in Reviewing and enhancing BDD scenarios as a group, is where a missing one is caught.

Held together, these principles keep each scenario aligned with a person’s need, readable by the owner and run as a test on every change.

The next lesson, on how BDD aligns development with user expectations, shows where that alignment holds, and where a scenario can pass while the need still fails.

Principles of behavior-driven development (BDD)

People and words

Behavior as scenarios

Checks that keep running

Marketing

Design

Development

Automation

Local