Behavior-driven development (or BDD) is an agile software development technique that encourages collaboration between developers, QA and non-technical or business participants in a software project.

Behavior Driven Development (BDD), as its name indicates, is not a testing technique, but rather a development strategy (as well as TDD, which is test-driven development). What it proposes is to define a common language for the business and the technical team members, using it at the outset of development and testing, hence why it’s important for testers to understand BDD.

What is a feature file and what does it contain

Feature files are text files with .feature extension, which can be opened by any text editor as well as readable by any BDD-aware tool, such as Cucumber, JBehave or Behat.

Feature files should start with the context of the feature (which is essentially the story), followed by at least one scenario in the following format

Feature: Some descriptive text of what is desired

To realize a named business value
As an explicit system actor
I want to gain some beneficial outcome that furthers the goal

Scenario: Some determinable business situation

Given some precondition
And some other precondition
When some action by the actor
And some other action
And yet another action
Then some testable outcome is achieved
And something else we can check happens too

Scenarios in feature files should focus on the “what” rather than the “how”. The scenarios should be concise and to the point so that the reader can quickly grasp the intent of the test without having to read a lot of irrelevant steps.

Why should we write feature files

As mentioned before, the primary aim of the BDD methodology is to encourage communication amongst the delivery team. The aim of the feature files is to document the scenarios talked through in order to give an indication of how much work is involved in delivering the feature. The feature files are also the drivers for automated tests. Feature files also serve as a definition of done (DoD), meaning that when all the scenarios have been implemented and tested successfully, we can mark the story as done.

Who should write feature files

It doesn’t really matter who actually writes/types the feature files, it could be any member of the delivery team, however, the contents (scenarios) which are discussed by a trio of Dev-QA-BA are the essential part of feature files. Getting a shared common understanding of the feature is the key element.

When should feature files be written

Feature files should be written during the story grooming sessions where the details of each story is discussed. Feature files containing scenarios should be written before development starts so that developers as well as QA have a clear understanding of the intent of the story. There should be a shared understanding of the story. The scenarios serve as requirements to development.

Where should feature files be kept

There should be one source of truth serving both as specification and automated execution, therefore should be kept somewhere where every member of the team has easy access.

Having said that, because the feature files are the drivers of the automated tests, they should ideally be kept in source control system (GitHub) so that any updates to the feature files is immediately reflected on to the tests.

For non-technical members who have no experience with Git, we can always execute a dry-run of the feature files which will then output the list of all existing scenarios without actually exercising the feature files.

How should we write feature files

There are generally two ways of writing feature files - Imperative and Declarative

The imperative style of writing a feature file is very verbose and contains low-level details and too much information.

Pros: the person reading the feature file can follow the step-by-step

Cons: Because of too much detail, the reader can lose the point of the story and the tests. The feature file becomes too big, difficult to maintain and likely to fail due to UI updates.

The declarative style of writing a feature file is concise and to the point, and contains only relevant information about the story.

Pros: The declarative style is more readable as it contains fewer steps in the scenario. The reader can easily understand the scope of the test and quickly identify if any key elements are missing.

Independence of Scenarios

Scenarios should be independent of one another. This means that every scenario is stand-alone and should not refer to or depend on functionalities/conditions in other scenarios.

Redundancy and Refactoring

• Avoid repetitions! Repetitions or identical steps indicate the need for refactoring. Refactoring denotes that a scenario should be split into multiple ones while the original meaning is preserved.

• How many Givens, Whens and Thens (including Ands andButs) should you use? As a rule of thumb, there should be a maximum of 3 to 4 consecutive Givens and Thens. Otherwise this indicates a need for refactoring. Whens should be used very sparingly! Usually only include one When.

• Generally, favor many simple scenarios over a few complex ones.