BDD and Unit Testing

Updated October 4, 2026· Development

Behavior-driven development (BDD) and unit testing check software from two ends. A scenario asks whether the software does what a user needs; a unit test asks whether one piece of code gives the right answer. Each has its own job, and together they cover the software from what a user notices down to a single function. Here is what each does, and how they divide the work.

Behavior-driven development (BDD)

BDD defines and verifies the software’s behavior from the user’s perspective, so the software meets what users expect and what the business requires. Its scenarios, usually in Given-When-Then form, describe how the software should behave in each situation, naming behavior a user would notice in the owner’s own words.

Most of them run below the interface, as the point on test coverage explains below.

Unit testing

A unit test checks one unit of code, such as a function, a method or a class: given these inputs, is this the right output? Developers write them to catch bugs early, keep the code maintainable and make sure each unit does what it is meant to.

How BDD and unit testing work together

Alignment with user expectations: Scenarios describe user interactions and their expected outcomes, so everyone understands the behavior from the user’s side, and the software is held to what users expect and the business requires.
Testable specifications: Scenarios are specifications you can run: each is the basis of an automated acceptance test. Scenarios cover the “what”, under the story that gives the “why”; unit tests cover the “how”, one unit of code at a time.
Validation of behavior: Under the scenarios, unit tests check that the low-level pieces, individual functions and methods, behave as expected.
Early issue detection: Both catch problems early: scenarios catch behavior a user would notice, and unit tests catch bugs in the code beneath it. A problem caught early takes less time and money to fix.
Test coverage: BDD scenarios describe behavior a user can name, and on the Sean Dinwiddie’s Webmastery team most of them run below the interface, against a slice’s reducer and selectors or an RTK Query endpoint. End-to-end tests stay few and cover the critical journeys, while unit tests cover the pure functions underneath. The lecture Modern Redux Architecture Patterns sets out which test covers which layer.
Documentation and communication: Scenarios are living documentation that the owner and the webmasters both read; unit tests document how each unit of code is meant to work.
Regression testing: Both run on every change, so a change that breaks what already worked fails a test before it reaches the owner.

Stacked by layer, the suite has a shape:

The suite the course builds, by layer. Unit tests pin every case of the pure functions at the base, scenarios run at each layer that holds part of a behavior, and a few end-to-end journeys cross the top. Each rule is tested once, at the lowest layer that shows it.

Challenges and considerations

Overlap: Some scenarios cover ground a unit test covers too. Test each rule once, at the lowest layer that shows it: a scenario covers the behavior a user can name, and a unit test covers the edge cases of the pure function beneath it.
Integration testing: On the team, the scenarios at the endpoint and the view are integration tests already: each runs in a real store, with a stand-in only at the network, so separate integration tests stay few.
Test maintenance: Scenarios and unit tests both need upkeep as the software evolves. A test changes in the same commit as the behavior it checks, so the suite never describes software that no longer exists.

The rule behind the examples. One feature, scope to launch puts each test where its rule lives. An empty order, an unknown product and a bad line are rules of validateOrder, a pure function, so they are unit tests that compare its result as plain data, with no database, no server and no screen, and the written scope never names them.

A declined card is behavior an owner can name, so it is a scenario, run under its own name at each of the four layers that hold part of it, and one journey runs end to end because each layer’s test has already proved its part.

The rule bends where a scenario and a unit test overlap on purpose. In The view stays minimal, the view’s scenario and orderNotice’s unit test both check that a declined card asks for another, and they fail for different reasons:

Break the wiring, say a view that never renders its status line, and only the scenario fails.
Break the words that ask for another card and both fail, but the unit test names the function and the case.
Break the words for a dropped connection, which no scenario names, and only the unit test sees it.

So the overlap stays thin: the scenario checks the one case an owner would name and matches only the words that carry the behavior, and the unit test pins every case word for word. The lecture Practical Applications of Functional Programming tests every branch of a pure function the same way.

So a scenario tests behavior a user can name, at the lowest layer that shows it: on the Sean Dinwiddie’s Webmastery team, usually a slice, a selector or an endpoint rather than the screen. A unit test pins the cases of the pure function beneath it. Together they keep the software doing what its users need, and each failure points to its cause. BDD testing framework, next, runs one cart scenario both ways, in cucumber-js and in Vitest, against the same reducer.

Behavior-driven development (BDD)

Unit testing

How BDD and unit testing work together

Challenges and considerations

Marketing

Design

Development

Automation

Local