METHODOLOGY

BDD

Behavior-Driven Development

Write tests in language the business stakeholder can read. Then make those tests pass.

Last reviewed: 2026-05-24 byKevin Riedl wiki β†—

Behavior-Driven Development is TDD with the test language rewritten to be readable by non-engineers. Tools like Cucumber use a Given/When/Then format that a product manager can sign off on. The intent is to keep tests aligned with the business behavior they validate, instead of with the implementation that happens to exist today.

In practice the value is highest at the integration and acceptance test layers, where the language barrier between engineering and product actually causes bugs. At the unit-test layer BDD adds more ceremony than it saves.

// FAQ

FAQs

FAQs

Not either/or. BDD is most useful at the acceptance and integration layer, where engineers and product need a shared language. TDD is useful at the unit-test layer, where the audience is other engineers. Most production teams use both, at different layers.
At the unit-test layer, almost always. Writing ‘Given a user with X, When they do Y, Then Z’ for a function that adds two numbers is ceremony. Save Gherkin for the tests where the business stakeholder actually reads them.