How To Write BDD Test Scenarios
How To Write BDD Test Scenarios
Before we start to understand about the BDD test scenarios. Let’s basic idea about the BDD
and TDD and different between them.
Both BDD and TDD refer to the methods of software development employed by your
engineering team. There are broadly 2 mainstream approaches to development: test driven
development is one and behaviour driven development is the other.
BDD stands for behaviour driven TDD stands for test driven development.
development
The primary goal of behaviour driven Test driven development is primarily
development is to solve the problem of concerned with the principle of unit testing
communication between the business
(including the product manager), the
engineering team and the machines.
The aim of behaviour driven development TDD perform testing specific, individual
is to reduce the cost of translation. units of code
Broadly speaking, BDD is meant to The primary focus in test driven
eliminate many of the issues that TDD development is to ensure that the unit tests
introduces. BDD tests use a more verbose pass and that the ‘build’ is green.
language so that they can be read almost
like you would read a sentence.
BDD principles can help you and your TDD is focusing exclusively on the code
team shift your mindset towards the itself i.e. the technical aspects of a system,
behaviour of your product so that testing disregards the human, or behavioural
isn’t from a purely technical perspective. aspect of your application.
Your first question is probably ‘what are BDD scenarios?. That’s a fair question!
A BDD scenario is a written description of your product’s behaviour from one or more users’
perspectives.
Scenarios are designed to reduce the cost of translation and make it easier for your engineers
to understand the requirements and for your QA.
Using BDD scenarios means requirements and tests can be combined into 1 specification. In
some cases, the scenarios that are written can then be easily converted into automated tests.
BDD scenarios tend to follow a specific format. The format is fairly straight forward, and
with a little practice you’ll be able to write your own.
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)
Here’s a basic BDD scenario which describes the LinkedIn signup process:
If you have more than one or you require more information than this, you can add them with AND.
Using ANDs
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)
Your BDD scenarios should form part of 1 specification. This includes both the user story
and the scenarios. So, for example, if you’re writing a user story in JIRA or some other
beloved backlog management tool you could structure your specification in JIRA in the
following order:
1. User story – start with the user story describing the requirements from a user’s
perspective
2. BDD scenarios – then include your scenarios describing the behaviour of the system
to assist with testing
A user story has a slightly different structure to your BDD. Your user story should comprise
the following:
As an X
I can / want Y
So that Z
BDD scenarios are not necessarily mandatory across all of your product specifications. If
they were you’d spend most of your life writing BDD scenarios which would clearly be very
unpleasant.
BDD scenarios are best suited to specifications where you think there is a likelihood that the
requirements may be misunderstood without them or that a more thorough testing approach
needs to be adopted. If you’re working on a small color change, text change or a technical
chore / bug, there will clearly be no case for using BDD scenarios as this would be a waste of
everyone’s time.
It may be that you as a team decide to write them for all major new feature stories or that you
only focus on a specific type of specification. BDD scenarios can assist you in your
development process but as with all things product, you and your team should decide on what
works best for you.
BDD Tools
Cucumber:
Cucumber is a test framework that supports BDD. In Cucumber, the BDD specifications are
written in plain, simple English which is defined by the Gherkin language. In other words,
Gherkin is a language that Cucumber understands. Gherkin presents the behaviour of the
application used, from which Cucumber can generate the acceptance test cases. Cucumber is
a framework developed by Ruby that can work across different technologies.
Spec flow:
Spec flow evolved from the Cucumber framework using Ruby on Rails, and is used mainly
for .Net projects. Spec Flow also uses the Gherkin language.
If you plan to implement BDD, here are a few points that will benefit the software team.
Disadvantages of BDD
Even the best development approaches can have pitfalls and BDD is no exception. Some of
them are: