Behaviour-Driven Development popularly known as BDD, is a methodology for developing software through continuous example-based communication between developers, QAs and BAs.
In this article we discuss some Best BDD Practices to get the most out of it.
The primary purpose of BDD methodology is to encourage communication amongst the stakeholders of the project so that the context of each feature is correctly understood by all members of the team (i.e. shared understanding), before development work starts. This helps in identifying key scenarios for each story and eradicating ambiguities from requirements.
In BDD, examples are called Scenarios. Scenarios are structured around the Context-Action-Outcome pattern and are written in a special format called Gherkin. The scenarios are a way of explaining (in plain English) how a given feature should behave in different situations or with different input parameters.
Because Gherkin is structural, it serves both as a specification and input into automated tests, hence the name “Executable Specifications”.
1. 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 and is readable by any BDD-aware tool, such as Cucumber.
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:-
2. Scenario 1: User successfully created a Facebook Account
° GIVEN John is on the Facebook Registration page
° WHEN he enters all required registration fields
° THEN a Facebook account is created
All written BDD scenarios should be given a header which accurately describes the scenario you’re interested in.
In its simplest format, there are 3 key elements in any BDD scenario:
° GIVEN (describing the context)
° WHEN (describing the action)
° THEN (describing the outcome)
When you require more information in a scenario, an ‘AND’ can be used after any of the descriptors:
° GIVEN (context),
° AND (further context),
° WHEN (action/event),
° AND (further action/event),
° THEN (outcome)
° AND (further outcome)
Now, let’s revisit our Facebook registration scenario and flesh it out in more detail with a few ANDs.
° GIVEN John is on Facebook Registration page
° WHEN he enters all the required registration information
° AND he hits ‘Sign Up’
° THEN his Facebook account is created
° AND he is directed to the profile creation page
° AND his confirmation email is sent
To better understand, let us use a different scenario as another example,
Feature: A concise yet descriptive text of what is desired.
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.
Once you get started with Cucumber, the question is how to write your features.
° How can you keep your features maintainable so you don’t have to correct them after each change in the application?
° How can you reuse steps most efficiently?
° What are typical Cucumber smells?
Here is a list of 5 best practices that help us in our daily Cucumber life at gen Z.
3. 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.
4. Insert a narrative
Narratives describe in about one sentence what a feature does. Typical narratives contain a benefit for the user, a role that needs the feature and the feature itself. Narratives are important to envision why you are implementing a feature in the first place. They also give a short overview of the feature so others get a rough understanding what it is about without reading the scenarios.
5. 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. This is not a general rule though. There may be reasons for conjunctive steps. However, most of the time it’s best to avoid them.
6. Reuse step definitions
In Cucumber you can reuse steps in other steps. This comes in handy when a step extends another step’s behaviour or defines a superior behaviour that consists of multiple steps. You should try to reuse steps as often as possible. This will improve the maintainability of your app: If you need to change a certain behaviour, you just need to change a single step definition.
7. Use backgrounds wisely
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.
