|
| 1 | += BDD (Behavior-Driven Development) |
| 2 | +:categories: testing-quality |
| 3 | +:roles: software-developer, qa-engineer, business-analyst, product-owner |
| 4 | +:proponents: Dan North |
| 5 | +:related: tdd-london-school, tdd-chicago-school, user-story-mapping |
| 6 | +:tags: bdd, gherkin, cucumber, specification-by-example, three-amigos, given-when-then, living-documentation |
| 7 | + |
| 8 | +[%collapsible] |
| 9 | +==== |
| 10 | +Also known as:: Specification by Example, Executable Specifications |
| 11 | + |
| 12 | +[discrete] |
| 13 | +== *Core Concepts*: |
| 14 | + |
| 15 | +Given-When-Then:: Structured scenario format — Given a precondition, When an action occurs, Then an expected outcome results |
| 16 | + |
| 17 | +Specification by Example:: Concrete examples as executable specifications that define system behavior |
| 18 | + |
| 19 | +Three Amigos:: Collaborative discovery sessions between developer, tester, and business representative |
| 20 | + |
| 21 | +Gherkin syntax:: Domain-specific language for writing human-readable, machine-executable scenarios |
| 22 | + |
| 23 | +Living documentation:: Tests that serve as always-current system documentation |
| 24 | + |
| 25 | +Outside-in specification:: Start from desired business behavior, work inward to implementation |
| 26 | + |
| 27 | +Ubiquitous language:: Shared vocabulary bridging technical and business stakeholders in scenarios |
| 28 | + |
| 29 | +Discovery workshops:: Structured conversations to uncover requirements through examples before implementation |
| 30 | + |
| 31 | + |
| 32 | +Key Proponent:: Dan North ("Introducing BDD", 2006), creator of JBehave which influenced Cucumber's design (Cucumber created by Aslak Hellesøy, 2008) |
| 33 | + |
| 34 | +[discrete] |
| 35 | +== *When to Use*: |
| 36 | + |
| 37 | +* Cross-functional teams needing shared understanding of requirements |
| 38 | +* Systems where business rules are complex and need clear documentation |
| 39 | +* Projects requiring executable acceptance criteria |
| 40 | +* Bridging communication gaps between technical and non-technical stakeholders |
| 41 | + |
| 42 | +[discrete] |
| 43 | +== *Related Anchors*: |
| 44 | + |
| 45 | +* <<tdd-london-school,TDD, London School>> - Outside-in development approach that complements BDD |
| 46 | +* <<tdd-chicago-school,TDD, Chicago School>> - Developer-focused TDD practice |
| 47 | +* <<user-story-mapping,User Story Mapping>> - Requirements discovery that feeds BDD scenarios |
| 48 | +==== |
0 commit comments