BDD libraries like Spock, allow us to create nice descriptive tests. But if we want really to follow the BDD concept we must use business vocabulary when writing them. In this article we will show you our approach to this topic

Being too technical

As an example we will use a domian of air conditioners service and guarantee repairs. Let’s imagine that we design a use case which will calculate the price of a service. This price will be put on a bill and sent to the customer. Let’s assume that we use commands and handlers. The most straightforward approach might look like that:

Looks pretty ok, right ? We could even add the descriptors in the given/when/then lines which will make it even more pretty, right? Not exactly… We have too many details here. This kind of details are scary and definitely not pleasant to the business people.

How to use the Fixture

So how to hide these unpleasant things ? Use the Fixture which is part of the Spock framework! Fixture is nothing more than a scope of class level variables which are initialized separately for every test plus a set of functions using them. We can keep fixutre variables on the technical level of abstraction and create a dedicated set of functions which will expose only business meaning. The effect might look like that:

In the given  block we initialize all the necessary fixture variables. In the when block you can see serviceIsFinished() function. It is using previously initialized variables in the following manner:

Is it simple? I would say yes :). The effort to structure the test like that is minimal and the result we get  can be read by a business person without a problem.


Do you think that the shown method of structuring the BDD tests is worth the hassle? Or maybe it was obvious to you already? Please leave a comment if you have anything to share 🙂

Categories: Tests

Leave a Reply

Your email address will not be published. Required fields are marked *