Past Meetup

Domain Language throughout Tests, combining DDD and BDD and Feature Mapping

This Meetup is past

42 people went

Location image of event venue


In the upcoming meetup we will have a trial run talk for and a feature mapping hands-on session.


18:00; - 19:00: Entry + drinks + food

19:00 - 20:00: Talk (Trial Run) -

Domain language throughout tests by combining DDD and BDD

20:00 - 20:15: Break

20:15 - 21:30: hands-on: Feature mapping - a simpler path from stories to executable acceptance criteria

21:30: Drinks and networking

Talk: Domain language throughout tests by combining DDD and BDD

While software engineers are beginning to use the language of the domain (business language) more in their application code, in most tests we still see a lot of technical language. Especially when creating acceptance test for a GUI, we mostly go from gherkin to Selenium straight away! With the ever-growing culture of creating living documentation in the form of gherkin, it is evenly important to use the domain language in our test code too.

In this talk, I will explain how to combine Domain Driven Design (DDD) and Behaviour Driven Development (BDD). With event storming and BDD techniques like OOPSI and Feature mapping we can create a ubiquitous domain language that we can use in our application and test code. Using property-based testing and the Screenplay pattern, I will show several examples on how to use the domain language in test code. As a result, we have tests that are both useful for communication and serve as living documentation based on our domain language.

Hands-on: Feature mapping - a simpler path from stories to executable acceptance criteria

(from the following article: )

Writing good acceptance criteria is one of the keys to effective software delivery. But it’s hard.

Feature Mapping is a simple collaborative practice designed to help teams write great executable specifications. Feature Mapping draws on Jeff Patton’s Story Mapping (, Matt Wynne’s Example Mapping ( and other techniques.

In a nutshell, the process goes something like this:

• Define a feature or story, or pick one from the backlog

• Understand what actors are involved in the story

• Break the feature into tasks to identify the main flows

• Identify examples that illustrates a principle or variant flow. Ask questions like “But what if…”, “what else could lead to this outcome”, “what other outcomes might happen”, and use the answers to create new examples. Use rules to explain and give context to your examples

• Rinse and repeat for other rules and examples

• Create Executable Specifications: automate the main high-level flows with pending steps