bdd-principles

Write scenarios in Given/When/Then format describing observable behavior in business language, not technical implementation details. Group related scenarios under business rules, use concrete examples with real values, and keep each scenario focused on a single behavior.

BDD is business-focused and uses collaborative examples to define what to build, while TDD is developer-focused and uses unit tests to guide how to build it. They complement each other: BDD drives outside-in development from user behavior, TDD drives inside-out code design.

BDD scenarios should document key business behaviors and rules that stakeholders care about, while unit tests cover technical details and edge cases. If a scenario describes implementation mechanics rather than observable business behavior, it belongs at the unit test level.

Bring together business, development, and testing perspectives to explore a feature through concrete examples before implementation. Each role challenges assumptions: business defines value and rules, developers raise constraints, testers probe edge cases and failure modes.

Example Mapping is a workshop technique using four card colors: yellow for stories, blue for rules, green for example scenarios, and red for open questions. It structures discovery conversations and quickly reveals ambiguities and unknowns in a feature.

No, BDD is a collaborative practice for discovering requirements through conversation and examples; tools like Cucumber only automate the resulting scenarios. The core value is shared understanding between business and technical teams, not the tooling.