In this blog, we will focus on understanding the best practices that we should follow while writing Feature files using cucumber.
The very benefit of writing a feature file is that Behaviour of the application really pops out of it and next best thing that system should implement is really evident. but sometimes while writing feature files we get carried away and our feature files also start looking like big old requirement documents. So here are guidelines that we should follow to harness benefits of BDD:
Write declarative features
- Scenarios should be written like a user would describe them.
- Beware of scenarios that only describe clicking links and filling in form fields, or of steps that contain code or CSS selectors.This is just another variant of programming, but certainly not a feature description.
- Declarative features are vivid, concise and contain highly maintainable steps.
- Each Scenario must make sense and should be executed independently of any other Scenario.
- Feature files are easier and fun to understand
- You can only run a subset of Scenarios, as all the required Steps of a Scenario are mentioned in the Scenario itself
- In comparison to dependent Scenarios, independent Scenarios will be more eligible candidates for parallel execution
Insert a narrative
- Narratives describe in about one sentence what a feature does.
- Narratives are important to envision why you are implementing a feature in the first place.
- Typical narratives contain a benefit for the user, a role that needs the feature and the feature itself.
- They also give a short overview of the feature so others get a rough understanding what it is about without reading the scenarios.
Avoid conjunctive steps
- When you encounter a Cucumber step that contains two actions conjuncted with an “and”, you should probably break it into two steps.
- Sticking to one action per step makes your steps more modular and increases reusability.
- There may be reasons for conjunctive steps. However, most of the time it’s best to avoid them.
- This comes in handy when a step extends another step’s behavior or defines a superior behavior that consists of multiple steps.
- You should try to reuse steps as often as possible. This will improve the maintainability, If you need to change a certain behaviour, you just need to change a single step.
Use Background but judiciously
- If you use the same steps at the beginning of all scenarios of a feature, put them into the feature’s Background.
- Background steps are run before each scenario.
- But take care that you don’t put too many steps in there as your scenarios may become hard to understand.
Once you above mentioned guidelines in writing feature files, you will observe a drastic change in the quality of feature files and the change would be on better side only. Feel free to share your feedback if your experiences are otherwise.