Here’s a handy checklist for your team to apply to Gherkin scenarios and feature files. Feel free to use them to guide you when reviewing Gherkin scenarios at your code reviews.
Remember: Gherkin scenarios deserve the same level of scrutiny from the team as your application code.
Feature files should be limited to scenarios of related functionality.
Don’t just try to pile all kinds of scenarios into one single feature file. Make sure they are at least related to one another. On that note, limit the number of scenarios per feature. I would not want to put an absolute limit on it. But be reasonable; make sure it makes sense. There are some who would want to impose a limit of 5 or 6 scenarios per feature file but that can be an overly rigid approach. Do whatever makes sense for you and your team.
Limit the number of steps per scenario to something readable and reasonable.
Some people would like to impose some limit of 10 or 20 steps per scenario. And even though I’ve seen scenarios that go well above 100 lines, I still would recommend against being too rigid about an absolute limit on the number of lines per scenario. Just do something that makes sense for you and your team.
Use consistent spelling and grammar.
Consistent spelling and grammar will ensure that your automated tests are a lot more reusable. Even minor differences in spelling and grammar will lead to more Cucumber step definitions. Consistency will lead to better reusability and maintainability.
Do not use punctuation at the end of step phrases.
Cucumber does not like step phrases that end with periods, commas, or semicolons. Just don’t do it.
Learn more about Gherkin writing and Behavior-Driven Development – watch this full presentation.
Contact us to schedule a custom private workshop on Gherkin and other Agile topics.
