Introduction to BDD and an example of BDD

1. Behavior Driven
Development
Writing Software That Matters
Tarun Sukhani
Friday, May 11, 12 1

2. What is BDD?
Behavior Driven Development (BDD) is about implementing
an application by describing its behavior from the
perspective of its stakeholders.
Test Acceptance Test
Development Team Driven Driven Business Analysts
- Implement Vision Development Behavior Planning - Translate Vision
Driven
Development
Domain
Incidental Stakeholders Driven Core Stakeholders
- Support Vision Design - Articulate Vision
Friday, May 11, 12 2

3. How did BDD originate?
Analysis Phase of SDLC was being TDD is not a design tool - it leads
overlooked for automation... to emergent design at a granular
level...
Planning
This in turn leads to brittleness
Analysis because the structure of the
objects we are testing starts to
Design take precedence over the
interaction and behavior of those
Implementation
objects.
Maintenance
Friday, May 11, 12 3

4. Principles of BDD
Enough is enough, or
YAGNI (You Ain’t Gonna
Need It)
Deliver stakeholder value
Everything is behavior
Outside-In Development
Friday, May 11, 12 4
- Enough is enough. We should work to achieve the stakeholder’s expectations but avoid doing more than we need to do. YAGNI principle.
• Deliver stakeholder value. There are multiple stakeholders— both core and incidental—and everything we do should be about delivering demonstrable value to them.
• It’s all behavior. Just as we can describe the application’s behavior from the perspective of the stakeholders, we can describe low-level code behavior from the perspective of other code that uses it.

5. BDD by example
GroupEat
An application that allow groups of people to order food online from registered
restaurants and have their order emailed or SMSed to the restaurants for pickup or
delivery.
Features should Highlights
Used to group Features are not potential pitfalls
only be included
features the same as or areas of
if they help to
together stories! greater concern
fulfill this SMART
Establish Identify Identify Identify Identify risks
vision or outcomes or feature sets or features and and
purpose goals themes stories assumptions
1. Able to order from different 1. Restauranteurs should be 1. SMS integration
Make group food ordering to 1. User registration
restaurants able to create menus 2. Market interest
multiple restaurants easy and 2. Order management
2. Keep track of group and 2. Users should be able to
convenient 3. Expense tracking
individual food expenses see a history of their orders
Friday, May 11, 12 5
SMART = Specific Measurable Achievable Relevant Time-boxed

6. GroupEat: Features and Stories
Evo he
ean t e
pE at mu
Grou sers to
st
Barack er,
um
do yo rder or th
u By us ing the o it?
allow ir order ak ng
e
eck th ry. one m ne receivi
ch o
wo
histo ave t
eh
t case, w fore two
In tha nd there
a res.
r oles, ent featu
differ
Stakeholder Business Analyst
Evo Barack ke them
’s ma tures:
two
let
G reat, rate fea t to
ant
OK. I w le sepa er, I wan at I
Yeah, be ab ac ustom tory so th .
oles to 1. As rder his pending
both r rder o s
to check o check my much I’m I want to
w r,
history. kn ow ho tauranteu y so that I
s r
2 .A s a re rder histo arning.
o e
k my much I’m
Stakeholder Business Analyst chec how
know
Friday, May 11, 12 6

7. GroupEat: Scenarios
Barack two
have ith
Kim scena s
rio f or
the
,I one t
He y Kim discuss w g G reat, ustomer i Restauran
to kin c r om .50
features volve chec or Item A f otal is $4
in is f order nd my t rant D on
. Both ory. One ther
you hist 1. If I ay 1 a
he o stau nI
o rder and t eur. Bo nD fr o m Re 3.00, the r
er em C total is $ my orde
stom taurant t
and I d my
the cu he res on
f or t an total
Day 2 see $7.50 page.
Business Analyst Tester shoul
d
histor
y
Evo in
at rem to filter
.I
ds me by Barack ak th
ose
, th re
Yeah be able see we can b er into
to hat I ly , then ures furth iewing
want anges so t ll on OK eat v
r
date tals that
fa
ge. two f at include range,
to te ran th
ories als by dat n a
e
order specific da er by st
tot
lt eve
w
a
ithin o like to fi items. order urant, or m.
s
I’d al t and foo
d resta icular ite
an part
re staur
Stakeholder Business Analyst
Friday, May 11, 12 7

8. Automating Scenarios
The Business Analyst ensures that the stories and respective
scenarios use the language of the stakeholders (ubiquitous
language)
Where it makes sense to do so, scenarios or test cases are
automated. Scenarios are made up of individual steps which
drive the direction of the development effort.
One of the most important characteristics of BDD is that the
scenarios are easy to automate and modify yet are still
understandable to the stakeholder.
Friday, May 11, 12 8

9. Gherkin: DSL for BDD
Gherkin is a Domain Specific Language (DSL) for BDD
It is i18n compliant and currently supports 35 different
languages
Gherkin grammar has the following keywords:
★ Feature
★ Background
★ Scenario
★ Scenario outline
★ Scenarios (or examples)
★ Given
★ When
★ Then
★ And (or but)
★ | (which is used to define tables)
★ """ (which is used to define multiline strings)
★ # (which is used for comments)
Friday, May 11, 12 9

10. GroupEat: Sample Feature
i18n support { # language: en
feature tags { @approved @release1.0
feature description { Feature: Customer checks order history
In order to monitor spending
As a customer
I want to check my order history
scenario tag { @sprint1
typical scenario { Scenario: Default order history (no filter)
@sprint2
edge case scenario { Scenario: Order history with date range filter
@sprint2
edge case scenario { Scenario: Order history with restaurant filter
@wip @sprint3
edge case scenario { Scenario: Order history with menu item filter
Friday, May 11, 12 10

11. GroupEat: Scenario Steps
Given: Indicates something that we expect to be true in a
scenario; e.g., Given I am logged in as a customer. It is not
the same as a precondition.
When: Indicates the event in the scenario. Preference is for
a single event in a scenario; e.g., When I view order history
page
Then: Indicates an expected outcome. OK to have more than
one (hence the And and But); e.g., Then I should see $7.50
for the order total.
Friday, May 11, 12 11

12. Scenario Styles
Declarative Imperative
Scenario: Default order history (no filter)
Scenario: Default order history (no filter)
Given I am logged in as a customer
Given I am logged in as a customer
And I go to the order form
And I order Item A from Restaurant B
And I select “Restaurant B” from “Restaurants”
And I order Item C from Restaurant D
And I select “Item A” from “Items”
When I go to the order history page
And I press “Add Item”
Then I should see $7.50 for my order total
And I select “Restaurant D” from “Restaurants”
And I select “Item C” from “Items”
And I press “Add Item”
When I go to the order history page
Then I should see $7.50 for my order total
Tend to be more customized to each scenario. Less More composable, meaning we can generally support
verbose, so less amenable to reuse. more scenarios with fewer step definitions
Friday, May 11, 12 12

13. Organizing Features
For larger projects or for features with lots of scenarios, we
can create subdirectories for each feature, with multiple files
in each subdirectory and with cohesive subsets of scenarios
in each file
We can also choose to organize by feature sets or themes,
each in its own subdirectory.
features
order management
order placement
order history
user registration
customer registration
restauranteur registration
restaurant management
customer management
Friday, May 11, 12 13

14. Tag usage
Once we get a scenario passing, any subsequent failure is
considered a regression. We want some mechanism to fix
failing scenarios quickly.
Tags allow for this by running only those features or
scenarios that we specify.
Other uses for tags include identifying scenarios only to be
run in a certain environment, representing different sorts of
testing, or related to a features set or theme.
Friday, May 11, 12 14

15. End with more Gherkin...
Background: Lets us write steps that will be invoked before
every scenario in a given feature.
Multiline Text: For software that uses text files as either input
or output.
Tables in Steps: When specifying tabular data in steps,
usually used with Given or Then.
Scenario Outlines: For similar scenarios, we can define an
outline for a scenario once, with placeholders for the values
that might change from scenario to scenario.
Friday, May 11, 12 15

16. GroupEat: Coding Example
Ruby on Rails Outside-In Development with Cucumber
1. Start with a scenario. Make user you understand the expected outcomes and how the UI should support a
user interacting with the application
2. Run the scenario with Cucumber. This reveals what step definitions need to be defined.
3. Write a step definition for the first step. Run the scenario with Cucumber and watch it fail.
4. Drive out the view implementation. You’ll discover assigned instance variables, controllers, controller actions,
and models that the view will need in order to do its job.
5. Drive out the controller implementation, ensuring that the instance variables are properly assigned. With the
controller in place, you’ll know what models it needs to do its job.
6. Drive out the models, ensuring that they provide the methods needed by the view and the controller. This
typically leads to the fields required for the database.
7. Once you have implemented all the models and the methods you discovered are needed, execute the scenario
with Cucumber again to make sure the step is satisfied.
Friday, May 11, 12 16