The complete guide to BDD + Cucumber Best Practices and Anti-Patterns.

The complete
guide to BDD +
Cucumber
Best Practices
and Anti-Patterns
with Test
Automation
BDD and tools like Cucumber, when used correctly,
should add significant value to your organisation’s
project delivery, product quality and customer
satisfaction.
…when used correctly…
And herein lies the problem. They are highly prone to
unintentional misuse that quickly diminishes their
value-add.
More often than not, the process and the tools are used
poorly and in a manner far from the intention of the
teams that built them.
In this webinar, we’ll take you through the complete
guide of firmly accepted best practices to embrace
and anti-patterns to avoid when starting to use these
tools and processes in your organisation.

Chair a collaborative
3-amigos
requirements forum
with your Product
Owners, Developers
and Testers.
Collaborate and communicate.
Discuss and Question the requirements.
Explore the What ifs and the Edge Cases.
Capture the agreed outcomes and desired
behaviours in a BDD Scenario.
Product Owners can outline a basic intent,
Developers can lead the technical discussion and
Testers can lead an exploration of the boundaries
and the unexpected.
Do not have Team Members write Features and
Scenarios in isolation.
Do not write BDD scenarios after you have already
implemented a feature.
BDD is first and foremost about a conversation. If
you’re not conversing you are not ‘doing’ BDD.

Focus on describing
the end-to-end
journey the customer
is undertaking, not
how they are
executing it.
Avoid combining
multiple requirements.
Bad
Given an unregistered user is on the Amazon UK website
When they click in the Search field
And enter ‘Headphones’
And click search
Then they see a Search Results page
When they select a product
Then they see a Product Details Page
When they add quantity ‘2’
And click on ‘Add to cart’
Then they are able to complete a successful checkout
● Choose declarative over imperative
● Embrace singularity
● Anyone should be able to immediately understand the flow
● The steps in Ex1 should be contained in the Step Defs only
● Changes in UI flow will break scenarios
Good
When they search for a product
And add it to cart
Bad
And add it to cart
And they can then register as a new user

Use your Given as a
starting journey state,
your When as a series
of user actions and
your Then as a
verification point.
● Past, present and Future tense
● Background Steps
● Feature Narratives
● And + But in moderation
● 1st vs 3rd person
Better - ‘Past, Present and Future’ OR ‘Present’ all the way
and introducing Narratives and Background steps.
Feature: UK Checkouts
As a user I wish to checkout with a product I’ve chosen
Background:
Given an unregistered user went to the Amazon UK website
Scenario: Successful Amazon UK Checkout
And add it to cart
Then they will be able to complete a successful checkout
OK - Bad Tense usage
Given I will go to the Amazon UK website
When I searched for a product
And added it to cart
Then I can complete a successful checkout
Use grammatically
correct, concise,
natural language
with basic business
process terminology
as required.

Positive and Negative
behaviours.
● Capture what should
happen as well as what
shouldn’t
● How should the
application fail gracefully
in the event of an
unexpected user
behaviour?
● Which error messages
should the customer see
in which circumstances?

If your working with a
Spanish customer, use
Spanish. Given a user is on the Amazon website
And add it to their cart
Then they can checkout successfully
Dado que un usuario está en el sitio web de
Amazon
Cuando buscan un producto
Y añádelo a su carrito.
Entonces pueden pagar con éxito
● Watch the buy-in of your
customer and the shared
collaboration with them
skyrocket if you can
embrace a local language
● In your requirements
management tool, for
example JIRA, why not
capture both versions? 1
for the customer and 1 for
the delivery team.

Don’t force the re-use
of scenario steps for
automation
convenience.
There are obvious examples where this makes sense -
“Given an administrator logs into the application”...
If the re-use of a step to achieve a certain sequence of
user/test behaviour does not break the readability or
logical flow of the BDD scenario, then it’s ok.
In your discovery sessions, the conversation and flow is
paramount. Document the natural language
requirements that are discussed.
Do not disrupt the ‘flow’ of your 3 amigos sessions by
hunting around for a step that you think already exists
just for its re-use.
People advocate step re-use for code maintainability’s
sake which is true, but implementing the page object
model will do exactly that anyhow.
Step re-use is also touted as an antidote to manageable
step definition files but not at the expense of best quality
readable scenarios.

Manage your Step
Definition files.
Understand that Step Definition files are unique
to tools like Cucumber. As such, there are
differing ways that they can be managed.
There is no one size fits all and this is probably
the least talked about aspect of BDD
implementation.
‘Technically it doesn’t matter how you name your
step definition files, or which step definitions you
put in a file. You could have one giant file
containing all your step definitions. However, we
recommend creating a separate file for each
domain concept.’
Common Practices
Link them with a parent feature
Manage them by maximum size
and create new Step Defs when
needed
Organise them by application
web page or mobile screen
Organise them by Given, When,
Then
Organise them by user and
application behaviour type -
navigating, verifying etc

Combine the Page
Object Model with the
Step Definitions.
This helps to keep step
definitions themselves
readable.
If re-usability of step definitions
is a team aspiration, this will
aid that.
Code maintenance then
resides at a single page class
and method level rather than
repeating common application
interactions present in multiple
steps.

Use of Cucumber
Example tables to
data drive your tests.
Focus on Test
independence.
Only parameterise
that which needs to be
parameterised.
Adding too many examples with too many
fields has the same effect as having too
many Scenario Steps. It reduces readability
and no-one is completely sure of what is
being proven.

Features, Scenarios,
Examples and Multi
Threaded test
automation.
Most BDD supporting test automation frameworks with multi-threaded test execution
enabled, will split the workload at the feature level. Why do we care?
For an optimised test execution runtime and an even load across threads, as much as is
practical without breaking your Feature/Scenario integrity, you should:
- Try and keep matching numbers of Scenarios across your Feature files.
- Try and keep balanced use of Scenario Outlines with Examples across your Feature files
- Otherwise you will find you have 1 or 2 slow, long running threads with an excessive
automation workload.

Do not use nested
‘steps within steps’ in
Cucumber.
Given /I complete an Amazon checkout/ do
steps %{
And add it to cart
}
● Horrific for
troubleshooting a failed
test
● Was only ever about
automation copy and
paste convenience and
never about the BDD
requirements discovery
● Even the architects of
Cucumber later claimed
they wish they had never
enabled it

Use of Hooks - Before,
BeforeAll, After and
AfterAll.
BeforeAll - before every test to
be run
Before - before any single test
using a specified tag
AfterAll - after every test to be
run
After - after any single test
using a specified tag
Before/BeforeAll - Useful for
providing a clean, known
starting state for tests
After/AfterAll - Useful for
‘tearing down’ after tests and
keeping your test
environments clean and
performant

Use of tags to include
and exclude scenarios
for testing, linking to
requirements ids and
denoting risk and
criticality.
JIRA Req ref
After Hook
Priority for Run

Living
documentation
and
requirements
traceability.
Use a test reporting format that
incorporates the Features and
Scenarios.

Ensure your tests
provide a service to
you as the customer.
Your supporting automated tests have a
job to do and they must be fit for
purpose.
Fix them or retire them.
Retire, but don’t remove redundant
Features and Scenarios.
If called upon right now, could you…
1. Execute a critical set of automated
regression tests?
2. With consistent performance?
3. With quick, clear reporting?
4. With failure diagnostics?
…so that you could advise a Delivery
Team Go/No Go meeting whether or not
to release to production in an hour.
Test your readiness now!!
Ensure your testing
team provides a
service to your
customers.

Test your BDD
Scenarios themselves.
Use the Requirements
Testing Checks.
Review and Test your Requirements
Is it complete?
Don’t add placeholders to your feature and scenario
repository.
Is it ambiguous?
Do the Product Owner, Developer and Tester all
understand what’s required?
Is it singular?
Avoid the ‘twinning’ and ‘cross pollination’ of scenarios
with multiple requirements. Single requirement, single
scenario.
Is it testable?
Does it document clear and measurable outcomes for
success?
Is it deliverable?
If everything above is true, consider your requirement
and your scenario deliverable!

The complete guide to BDD + Cucumber Best Practices and Anti-Patterns.

Recommended

More Related Content

What's hot (20)

Similar to The complete guide to BDD + Cucumber Best Practices and Anti-Patterns. (20)

Recently uploaded (20)

The complete guide to BDD + Cucumber Best Practices and Anti-Patterns.