In my previous post, I discussed why we want to write software with empathy in mind; software that is understandable for peers. For us to create software with empathy in mind, we need to create a shared understanding of the users’ needs; the needs we are trying to satisfy with our software. Practices like Domain Driven Design (DDD) and Behaviour Driven Development (BDD) can help us achieve this. By using Feature Mapping (a technique from BDD) and improving this with Event Storming (a technique from DDD), we can create executable specifications and a model for our business needs at the same time. This way, we can write software and tests that match the shared understanding the business has, which enables us to ship more value faster.
The practise of Behaviour Driven Development (BDD), and using tooling to support this like cucumber, has inspired many posts and talks. The recurring questions are predominantly about how teams and people pull these tools out of its collaboration context, and bring it into the test automation context. Cucumber’s post might perhaps be one of the best on this topic,
Last year I started giving talks about BDD based on my own experiences. One pitfall that always seems to pop up, at least in the Netherlands, is about imperative versus declarative (or implementation vs intention).