BDD 101 – Writing Good Feature File

“Profound things are simple. If it is not simple then it cannot be true. But simple things are difficult”

This quote is absolutely true for BDD as a methodology and tools implementing it as well. But most of the times we tend to lose the essence of even simple things by not focussing on the fine prints. In any BDD project, feature files are the essence of overall implementation, and this very fact gets lost in the drive to implement the definitions beneath it. In this article, we discuss some of the BDD writing Guidelines and Best Practices.

A poorly written feature file serves no purpose, rather it sets up the project for increased complexity, maintenance, overall development effort and eventually loses the goal of quality deliverables with behavioral feedback.

Unless a team sets out with common goal, proper guidelines and strict review checklists, it is very likely to have:

1. Features without proper functionality focus
2. Repeated and redundant steps
3. Lengthy scenarios leading to
   — Increased execution time
   — Increased flakiness

Behavior-driven development is an “outside-in” methodology. It starts at the outside by identifying business outcomes and then drills down into the feature set that will achieve those outcomes. Each feature is captured as a “story”, which defines the scope of the feature along with its acceptance criteria. – DAN NORTH & ASSOCIATES

At Wavelabs, we follow certain guidelines for each step of automation development, whether it is writing feature files the right way or removing the smell from code. Below are some of the questions which our developers ask before authoring any feature file:

Feature

1. Is a feature file aligned with one finite quantum of application functionality?
2. Does it articulate the purpose of feature very clearly?
3. Does it contain enough testing points/scenarios?

Background

1. Is background complementing all the scenarios?
2. Is background not having too many steps?
3. Is background independent from different inputs?

Scenario/Scenario outline

1. Are scenarios related to concerned feature only?
2. Will scenarios not take more than few minutes[maximum 5 minutes] to execute?
3. Are scenarios independent from each other?
4. Are scenarios being written from the user’s perspective?

Example tables

1. Does example table have enough data sets to check all conditions?
2. Are examples being tagged for future executions?

Steps

1. Are steps generic in nature?
2. Are steps utilizing data tables to reduce the number of similar actions?
3. Are steps utilizing keywords [Given, When, Then, But] appropriately?

If you have thought about various implications of the above questions and the answer for all the above questions is YES, then you are on the right track.

Below is the mind map containing best practices for writing a perfect feature file:

Want to know more about best practices, principles, frameworks and reusable assets? Get in touch with us by filling the below form.