BDD Guidelines - writing features - gherkin language
Some of us here are working on the BDD guidelines that should be followed:
Would be interested to hear if anyone has thoughts to share:
- Explain in the feature file what the feature is about, just after the “Feature:
” before proceeding to the scenarios (preferably in “In order/As a/I want” format).
- Write high-level scenario steps by raising the level of abstraction and focus on the “what” rather than the “how”
- don’t mention UI elements
- don’t mention ‘click’ or other actions linked to specific UI elements
- the scenario should remain valid if the UI is replaced with a new UI tomorrow
- avoid very detailed steps where possible (helps to focus and avoid clutter)
- Write scenarios using business language rather than using technical language so that it can be understood by everyone.
- Write scenarios from the perspective of the person who will use or needs the feature (not always a member or user). Use 'I' and explain who the 'I' is in 'Given' step.
- Each and every scenario needs to be independent, i.e. scenarios should not depend on other scenarios or data created by other scenarios.
- Don't mention features or actions which are not related to the actual feature under test.
- Example: Scenario is to check the balance is displayed currently in a user account. Before checking the balance, user needs to login to check the balance but Login is not part of the check balance scenario.
- Use Scenario Outline when you have several scenarios that follow exactly the same pattern of steps, just with different input values or expected outcomes.
- Scenario Outline examples should be easy to understand. Column names should be meaningful (e.g. | Contact Method | Enquiry Type | instead of | value1 | value2 | ), so that the steps are understandable.
- Scenarios need to be environment independent.
- Write scenarios for testing happy paths and important error cases.
- Avoid typos and always use grammatically correct English.
- Wherever possible steps should be reused. This can also be achieved by
- parameterizing (if applicable)
- keeping it short and simple
- Whenever a feature or behaviour changes the existing scenarios needs to be updated (from a latest branch in TFS)
- Actions, which are not directly related to the scenario should be handled outside the actual scenario:
- Actions like login should be handled part of Background or hooks.
- Setup and teardown should be part of hooks and should not be part of the scenario.
Same test as in Bad Example 1, but with focus on a single business rule and without UI stuff