For the last year I have been experimenting with the new approach to a Behaviour-Driven Development, which could be summarised as “Ubiquitous Language is a thing again”. The core premise of this approach is that if you take Ubiquitous Language seriously and push for it in your scenarios, you open the door to doing a Domain-Driven Design while you’re doing Behaviour-Driven Development’s red-green-refactor cycle. By embedding Ubiquitous Language in your scenarios, your scenarios naturally become your domain model, which you can use to develop the most important part of your application - a core domain.

End-to-end testing

End-to-end automation is the most common way of using Gherkin-based BDD tools. The first thing people think about when they see Gherkin is “I can test my website with this”. Nowadays we know that this is not the only way to use these tools. Matt Wynne has a brilliant article about this. You can indeed use your scenarios written in Gherkin to drive implementation of the lower layers of your application.

But even if you take the approach of avoiding end-to-end, your choice is still binary - you either drive your core domain with your scenarios, or you drive the interface. That is until you start treating the feature as a driver for different layers of your application. What if you can use the same feature to develop different layers of the application separately?

Not only can you avoid going end-to-end when you’re doing BDD, there is a way to test your application at multiple levels using the same behavioural examples. And as controversial as it sounds, this will make a lot of sense when you really dig into it.

Ubiquitous Language

For a long time we have been preaching that this:

Scenario: Showing delivery cost for a product on the basket page Given there is a product: | name | White Marker | | price | £5 | And I am on the