_edited_edited.png)
Genius is the ability to reduce the complicated to the simple – C. W. Ceram
Many a time, we make things unnecessarily complex when we can actually think, break it down and make it simple for ourselves as well as for others.
Having decided to make test automation a priority, you plan to use BDD (Behavior-Driven Development), selecting a good language for test automation, keeping in mind a BDD tool and when you are ready to write your first Gherkin feature file, you start thinking “How am I supposed to write?”
But before we look into what good Gherkin guidelines can be followed when you write a Gherkin script, let us see what Gherkin actually is:
Gherkin is a simple, easy to read, plain text language used to verbalize BDD. It is a language formalized to make the artifacts (requirements/acceptance criteria/tests) understandable to all people – business / stakeholders/ technical/ non-technical. High level notes are provided by Product Owners which “the three Amigos/ the Triad ” (business analysts, developers and testers) would collaboratively use to write feature files that give a desired product functionality involving multiple behaviors. These features are further divided into scenarios each describing one single behavior.
Gherkin scripts are written inside BDD tools (like Cucumber) using the Gherkin syntax also known as, G-W-T (Given-When-Then) syntax which allows testers and developers to continue working on the implementation of BDD. The main keywords used in Gherkin are:
Feature, Scenario, Given, When, Then, And, But
Image by David Travis from Unsplash
Just knowing the Gherkin format is not enough but using the format in the right way is important to complete the task. Good Gherkin feature files are not easy to write at first. The tough part here is thinking about all the scenarios and finally accomplishing 100% test case coverage. But with some basic pointers, and a bit of practice, Gherkin becomes easier. Let’s see some good practices to keep in mind while writing a Gherkin script.
The Ideal Gherkin Rule: "Wear the hat of the user”. Write Gherkin so that people who don’t even know the feature will understand it.
Use one feature per system functionality, making sure the feature is specific to a single functionality in particular and is as independent as possible from other functionalities.
The key to write a good Gherkin script is: One scenario should cover exactly one single, independent behavior to establish acceptance criteria.
It is suggested to write the positive scenarios first.
Select good titles which communicate in one concise line what the behavior is.
Limit the number of scenarios per feature.
Separate the behaviors by 3C’s: Comprehend - Communicate - Cover
Write behavior scenarios in a form which is readable and expressive; steps in a form that can be reusable.
Use as few as possible preconditions while still making the tests useful depending on the audience for your scenarios.
If your scenario is exceeding 5 steps, try to split it into two different scenarios – break it down to as modular as possible; even if it means to write several scenarios to make your test more complete.
Avoid coupling scenarios and make it as independent as possible
The less you have to read in each scenario, the easier to understand.
In a scenario, try limiting to one ‘G-W-T’ (in the exact order) step with maximum usage of two ‘And’ steps.
Focus on critical things and avoid duplicates.
Try grouping the features of a file related to one aspect of the application, thus making it better organized and easier to locate.
Writing scripts in third person (“the user”) perspective instead of a first person (“I, me, my”) is preferable, though there is no hard and fast rule - Consistent point of view, proper phrasing can favor clarity of what is written.
Write steps as a subject-predicate action phrase – always use present or present perfect tense for “Given” and present tense for “When”, “Then”.
The ‘But’ statement works the same as ‘Then,’ except that it is used when we want to verify that no concrete result is observed.
Capitalize Gherkin keywords; capitalize the first word in titles.
Remember Gherkin does not have an “Or” step; some programmers misinterpret Gherkin as a structured language.
Advantages:
More focus and less confusion
More visibility into team progress
Improved team collaboration by clarifying behaviors you want to develop
Each test failure points to a unique problem
Increased efficiency as reduced complex work and faster cycle times
Maintainable to reduce the costs of making changes in the test steps
Easy to rewrite scenarios as the products and features change
Below is an example where all the above mentioned good practices have been applied:
Practicing this Gherkin syntax not only does expedite automation but also helps focus specifically on the expected behavior of the product under development via scenarios, resulting in less ambiguity and a good overall solution for what to develop. Thus Gherkin helps the solution to be:
Clear. Concise. Complete.
Hope you enjoyed reading!