Take Good Care of Given-When-Then in the BDD

 BDD, Feature File & Gherkin Syntax

Behaviour Driven Development a.k.a BDD enforces agile team to write human readable, executable specification. Gherkin is a very nice Domain specific Language which support human readable syntax in different languages. BDD is all about bridging communication gap so writing better feature file is a key to success in the BDD projects.

Once you have all necessary communication with business, next step is to write feature files. Ideally, QA should take lead to write down all scenarios, preconditions and expected results in the form of feature files. Business analysts / product owners or even scrum masters can contribute to feature files. Once the team agrees all possible scenarios have been covered, then developers can kick start implementation.

Gherkin

Few tips to write better feature files

 1. Use Background

Gherkin is a Domain Specific Language used to describe features in the ‘GivenWhenThen’ format. Gherkin has some cool features in order to avoid duplication or repetitive steps. Gherkin helps readability for business users. Proper use of the ‘background’ feature of Gherkin can help to avoid repetitive tasks in each scenario. It is not mandatory to use ‘background’ in each and every feature, but it makes the feature file more readable. There are few things you need to keep in mind while using ‘background’. You have to keep your background section very short, just enough to keep the scenario in context. You shouldn’t include technical stuff like starting some services, clearing cache, launching browsers in the background, as the reader will assume these things. You’ll implement this in the step definitions by using proper hooks.

 

2.Use of Data Tables, Examples, Doc String, Multiple tables of example & nested steps

Gherkin provides ability to enhance your feature files by using tables. You can use ‘Data Tables’. Data tables allow you to set-up certain set of data as a pre-condition for the tests (Given) or as an example in assertions (Then).  You need to use ‘Scenario Outline’ to extend feature files by examples.  Doc String is another cool feature of Gherkin which allows you to hard-code ‘text’ into your feature files e.g. you can write email message in the quotes as an assertion. Gherkin also allows you to specify multiple tables of examples. Nesting Steps means hiding the implementation details.

 

3.Use tags and Sub-folders to organise features

Tagging the features/scenarios with certain tags helps categorise them into different groups. You can apply a filter to run the features/scenarios with specific tags. You can also create sub-folders according to the functionality to organise features effectively.

Here is an example feature file covering almost all the above mentioned points:

Feature: Login
In order to secure my website
,
as a business owner
,
I want to implement login functionality

Background: Given I am on login page

@wip @smoke @browser @ci

Scenario Outline: Check user's login credentials
Given I filled <username> <email> and <password>

When I clicked on Login

Then I should see <success or failure> message
 a
And I should get an email saying:
"Dear User,
You have just tried to login to our system. If your login is successful then you will get another email to verify you details. 
Thanks
"

Examples: Valid login
|username    |email          |password |success or failure |

|Andy        |andy@gmail.com |abcd1234 |success            |

|Mike        |mike@gmail.com |abcd1234 |success            |

Examples: InValid login
|username    |email          |password         |success or failure |

|Andy        |andy@gmail.com|                  |failure            |

 

Conclusion

The key benefits of Behavior-Driven-Development (BDD) practices are communication enhancement and customer satisfaction which can be achieved by better communication & better feature files. Hope you find these feature writing tips useful.

Happy BDD !

2 Responses to Take Good Care of Given-When-Then in the BDD

  1. Seb Rose says:

    Interesting post. Some comments:
    - It’s the step definitions that define your DSL. Gherkin’s keywords are a sort of BDD DSL themselves, but they aren’t the important DSL in my view.
    - Use background sparingly. Repetition is bad, but so is having to look at two places in a feature file to work out what’s happening. Locality of reference is valuable, so much so, that I generally prefer using step definition(s) within the scenario rather than in a background.
    - Nested step definitions are no longer recommended. See ‘The Cucumber Book’ (pp 75-78) and Matt Wynne’s notes on this old post http://blog.mattwynne.net/2008/11/14/dry-up-your-cucumber-steps/
    - Scenario outlines can be useful, but make sure that the format isn’t obscuring the meaning of the tests.

    • Shashikant Jagtap says:

      Hi Seb,
      Thanks for comments, Apologies for delayed responding. Here are my views on
      - I agree that step definitions is real DSL but human readable Gherkin will help non technical/Business people to understand what’s going on. Business people hardly look into step definitions.
      - I think, big advantage of using using background is when non-technical person writes feature file. If they understood system well enough they can abstract common behaviour which help in implantation. It can be achieved by hooks as well but again it depends on the context.
      -I just looked into Cucumber Book and it said its good idea to use nested steps in order to make scenarios easier for reading and refactoring. It is ‘Andew Premdas’ who has not recommended nested steps.
      In short, companies use DSL as how it fits into their culture.

Leave a Reply

Your email address will not be published. Required fields are marked *

* Copy This Password *

* Type Or Paste Password Here *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>