Organising scenarios and steps in Cucumber

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?

No 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.

A good division

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.

Conclusion

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.

Acknowledgements

I would like to thank Malin Ekholm for proof reading.

Resources



(less...)

Pages

About
Events
Why

Categories

Agile
Automation
BDD
Clean code
Continuous delivery
Continuous deployment
Continuous integration
Cucumber
Culture
Design
Executable specification
Gradle
Guice
J2EE
JUnit
Java
Linux
Load testing
Maven
Mockito
Pair programming
PicoContainer
Programming
Public speaking
Quality
Recruiting
Requirements
Scala
Selenium
Software craftsmanship
Software development
Spring
TDD
Teaching
Technical debt
Test automation
Tools
Web
Windows
eXtreme Programming

Authors

Thomas Sundberg
Adrian Bolboaca

Archives

Meta

rss RSS