Dan North: “…only Domain-Driven Design can tell me where I should or shouldn’t be focusing my efforts… once I determined that some computer system might help me, I need a way of getting … from concept to cash, from an idea of some outcome I want to a production software system making or saving me money. The way in which I get to that is Behavior-Driven Development, it’s the series of conversations, interactions, ways in which I express my domain desires as functioning software… ”
- How do you define Behavior-Driven Development?
- How does BDD relate to DDD?
- Sometimes I write tests to discover the language I need to express a story, and in this case, I call them “scenarios”. Then I even spell out TDD as “Test-Driven Design“. I noticed that in BDD you use the word “scenario” as well. Do we use it in the same way?
- Eric Evans always emphasizes “the power of concrete example”: take a story, break it down into concrete scenarios with numbers and talk through these scenarios to understand the story. You have written a tool called JBehave which formalizes this approach in the language of givens, actions and outcomes. Could you talk about your ideas behind JBehave?
- You designed a language around stories and scenarios, the triangle of given, when and then, where stakeholders, domain experts, testers and developers are responsible for some of its vertices. How do you see their responsibilities and interactions?
- Let’s go back to what you said about BDD being an exercise to remove the word “test”. So you removed “test” and replaced it with “should”. What difference did it make?
- In the beginning of our conversation you said that BDD and DDD are massively complementary. How do they complement each other?