Filed under: BDD, Cucumber, — Tags: Behaviour-Driven Development, Gherkin, Java — Thomas Sundberg — 2017-04-28
Writing a few scenarios in a feature file is easy. After while, when you have a lot of scenarios, you may want to divide them. How should you split them in such a way that finding a specific scenario is easy?
In the beginning it is easy to write the glue code needed to connect your scenarios with the system under test. But after a while it gets messy. You have a lot of methods and finding the one you need gets harder and harder. You need to start organising the steps in a good way to be able to find them without to much hassle.
These divisions can be done in a number of different ways. Some may support your development and maintenance. Other may hinder you. Is there an optimal division?
It is probably impossible to find a division of scenarios and steps that is universal and optimised for every project using Cucumber. But one axis that you may divide along may support quite a few projects. Perhaps so many that it ts worth a description.
The system you are working with probably has a some domain concepts. Each concept can be described either in a feature file or a few feature files in the same package. The same goes for the glue code you using to connect Cucumber and the system you are developing.
A rule of thumb can therefore be:
This division may not be optimal for you, but it can be a good start. When you find that you have other needs, move the scenarios and steps around to match them. The steps are global. Steps and scenarios don't have any connections to each other. Moving them around is a zero cost operation. You can try your new idea out and it won't cost you anything.
There is no optimal division for scenarios and steps. But dividing along a domian concept axis may be a good division. It is, however, good enough to give it a try if you feel that you would like to organise steps and scenarios different compared to how you divide them today.
I would like to thank Malin Ekholm for proof reading.
RSS