This Post’s Beginner terminology
- Gherkin – basically a small computer language with a well-defined syntax. A format of Cucumber specifications.
- Gherkin scenario – One of the basic Gherkin structures. Each feature may have several scenarios.
- Gherkin file – a feature file containing Gherkin scenarios.
- Epic (feature level requirements) – multiple User Stories including requirement of high level.
Let’s get to business.
Quality assurance is a huge field with lots of tricks. Here is one of such. Now that we are done with terminology that will be used in this post we may get going with our combinations. Now we are getting to the question that matters. Where do we put gherkin scenarios?
Let’s say we have a User Story written in cucumber. That user story came with associated Gherkin scenarios. So the main question is on where to put each scenario. The Bugs take place due to human nature. Programmers for some reason, known to them only (I don’t even know whether it’s psychological or intuitive) tend to associate every User Story to a separate Gherkin file. So your team is performing some test-first development. They will start writing Gherkin scenarios the moment their hands reach the User Story. Thus it will be nothing but natural to place these scenarios inside a new Gherkin file.
You can see an Epic ‘search for customers’ in this example. It has three user stories: the search by name, address, account number. It is possible for each User story to get a personal Gherkin file, let’s say a search-by-name feature. This is an easy way to go, yet even an easier way to get involved with some trouble. The user stories will demand some updates into the Gherkin scenarios and voila – your team is in a mess. User Stories are something like a very thin vertical slice that is going through the system. And they will certainly be rapidly followed by other exact same slices in the very same area. Having different Gherkin files makes the fact that all the functionality is being related at some higher level quite blurry.
That is but one example of making testing more complicated. Or simpler. Depends on the way you’ll be looking at things.