(note: you have to be logged in to see the video)
Key Takeaways
- "DDD is about focusing on the domain and let it affect the software very much." - Jimmy Nilson
This happens by having conversations. - Tho goal/output of BDD is a domain model, and the goal/output of BDD is examples.
- Concrete Examples help expose misunderstandings.
- Think of Gherkin as "english with some constraints".
- BDD is an evolution of TDD where the tests are sentences that are rooted in the domain and help us grow the ubiquitous language.
- In traditional TDD, it's hard to know where to start. BDD gives you a starting point (the conversation and Gherkin statements that result from it).
- Don't write Cucumber tests about UI interaction because then it loses the description of the domain.
- Regression tests are particularly important when the domain changes.
- DDD on testing- test context boundaries, layers, use CI.
- "The one where" to help get the right abstraction in your examples.
- You don't need to keep testing mundane things.
- Estimating Complexity and cynefin.
- Examples as not specifications, but as discovery.
- Try to think of additional outcomes that might happen (when trying to come up with Gherkin features / scenarios).
- Turn Unknown unkowns into known unknowns (and eventually knowns!).
- Examples illustrate user stories.
- Three levels of conversation:
- basic- having a conversation
- little more advanced- write down that conversation
- ultimate- create Gherkin scenarios tied to low level step definitions