Inside Behavior Driven Development

Inside
Behavior
Driven

Development

Bal$more
So+ware
Prac$ces
and
Pa2erns

April
19,
2016

Camille
Bell

cbell@CamilleBellConsul$ng.com

Twi2er
@agilecamille

ww.slideshare.net/Camille_Bell

Agenda

•  What
is
BDD?

•  What
is
its
value?

•  BDD
and
TDD
Similari;es
and
Diﬀerences

•  Who
par;cipates
in
BDD?

What
is
the
role
of
the
customer/product
owner?

•  Three
parts
of
Any
Test

•  Use
of
Business
Language
in
BDD:
what
is
a
good
BDD
test?

•  What
about
teams
that
have
tradi;onal
manual
testers?

•  What
about
teams
that
have
developers
but
not
testers?

•  What
should
be
tested
manually?

•  Demo


2

BDD/ATDD
==
Agile
Func;onal
Tes;ng

•  Many
names
for
the
same
thing:

–  Behavior
Driven
Development
(BDD)

–  Acceptance
Test
Driven
Development

(ATDD)

–  Story
Driven
Development

–  Story
Tes;ng

–  Speciﬁca;on
by
Example

•  We'll
call
it
Behavior
Driven
Development
or
BDD


3

BDD
By
any
Other
Name

•  There
are
some
minor
subtle
diﬀerences
between

those
terms,
that
don't
maSer
for
most
purposes

(Developers
tend
to
call
it
BDD
and
Testers
ATDD)

•  Collaborate
to
deﬁne
detailed
acceptance
criteria

before
developing
applica;on
code

•  Turn
the
criteria
into
executable
acceptance
tests

(before
developing
applica;on
code)

•  Watch
test
fail
(no
because
no
app
code)

•  Then
later
pass,
when
app
func;onality

implemented


4

Value
of
BDD
Over
Tes;ng
AUerwards

•  BeSer
Documenta;on
of
Requirements
–
Automated
tests

are
precise

•  Precise
Audi;ng
though
automated
traceability

•  Improved
Dev
Focus
–
Eliminates
Goldpla;ng

•  Clear
when
you're
done
with
a
feature

•  Eliminates
False
Posi;ves
that
tes;ng
aUer
can
cause

•  Ensures
acceptance
tes;ng
gets
done

•  Ensures
acceptance
doesn't
slow
down
release

•  Can
be
integrated
into
Con;nuous
Deployment
Pipeline

•  Regressionable
Spec

-‐
Obvious
if
code
and
tests
out
of
sync


5

Behavior
Driven
Development
&

Test
Driven
Development
Similari;es

•  Both
specify
behavior

•  Both
use
feedback
loops

•  Both
use
automated
tes;ng,
not
manual
tes;ng

•  Both
create
tests
with
3
main
parts

•  Both
create
tests
which
can
be
run
independently

•  Both
lower
defects

•  Both
provide
regressionable
safety
nets
for
change


6

Differences
Between
BDD
and
TDD
(1)

•  BDD
and
TDD
focus
is
different

–  BDD
focuses
on
building
the
Right
Thing
(business
value)

–  TDD
focuses
on
building
the
Thing
Right
(technical

quality)

•  BDD
and
TDD
have
different
levels
of
granularity

–  BDD
Scope
is
business
func;onality

–  TDD
Scope
is
soUware
class
and
unit
level


7

Differences
Between
BDD
and
TDD
(2)

•  BDD
and
TDD
par;cipants
differ

–  BDD
involves
a
greater
variety
of
par;cipants

–  TDD
is
developer
centric

•  BDD
and
TDD
specifica;on
languages
differ

–  BDD
test
specifica;ons
are
in
business
language

(e.g.

Cucumber's
Gherkin)

–  TDD
test
specifica;on
languages
is
in
programmer

focused
unit
tes;ng
language
(e.g.
JUnit,
Rspec,
CPPUnit,

NUnit,
etc.)


8

Test
Driven
Development
Feedback
Loop

Write
a
test
for

new
low
level

func;onality

Run
the
test
and

watch
it
fail

(no
code
=
test
fails)

Write
just
enough

code
to
make
the

test
pass


9

Run
the
test
and

watch
it
pass

Clean
up

complex
or

messy
code

Run
test
again

to
make
sure
it

s;ll
passes

Check
in

Code
&

Tests

Check
in

Code
&

Tests

Simpliﬁed
TDD
Flow

(oUen
called
Red-‐Green-‐Refactor

Write
a
failing
unit
test

for
new
func;onality

Write
just
enough

code
to
pass
test

Refactored
code
must

also
pass
tests,

no
new
func;onality


10

TDD
is
Deep
Inside
Code:
Tes;ng
at
Unit
Level

BDD
with
TDD
Flow
(simpliﬁed)


11

REFACTOR

RED

GREEN

RED

GREEN

REFACTOR

TDD

unit
test

level

BDD

acceptance

test
level

JUnit,

NUnit,

Rspec,
etc.

Cucumber

with

Gherkin

BDD
with
TDD
Inner
Feedback
Loop

(detailed)

Write
a
new

step
for
BDD

scenario


12

Clean
up

BDD

test
code

Run
BDD
test

again

to
make
sure
it

s;ll
passes

Check
in

Code
&

Tests

Check
in

Code
&

Tests

Focus
on

One

Scenario

TDD

unit
test

level

Run
Scenario

and
watch

Step
fail

Run
BDD
test

&
watch
step

pass

When
step

passes
pull

up
to
BDD

Drop

down
to

TDD

Three
Parts
of
Wri;ng
any
Test

Cucumber/
Gherkin

3
As

Ruby

3
As

Java

Formal
Testers
What
it
is

Given
Assemble
Arrange

Precondi;on
All
the
setup
and

dependencies
for
the

test

When
Ac;vate
Act
Ac;on/Event
Something
that

happens
that
will

make
the
outcome

diﬀerent
than
if
it

hadn’t
happened

Then
Assert
Assert
Expected

Results
or

Postcondi;on

What
is
expected
to

happen
and
any
side

eﬀects


13

Collabora;vely
(Spec
it/deﬁne
tests)

•  Some;mes
called

the
3
Amigos

(test,
dev,
business)

•  Conversa;on
based

•  Focus
on
value

•  Speciﬁc
examples

•  Concrete
data

•  Outside
in
(business
focus

drives
development)


14

BDD
Test
Automa;on
Has
2
Sides

Business
Facing

•  Simple
English

•  In
business
terms

•  Promotes
collabora;on

•  Uses
examples

•  Uses
concrete
data

•  Proves
business
needs
met

•  Executable
specifica;on

•  Modifiable
&
reusable

Technology
Facing

•  Exercises
underlying
SW

•  Connects
to
browsers,

networks,
databases,

frameworks,
etc,

•  Object
Oriented

•  Extensive
test
libraries

•  Modifiable
&
reusable

•  Learnable
programming

language


15

Quali;es
of
a
Good
BDD
Acceptance
Test

•  In
business
language
using
terms
common
to
that
domain,

so
that
your
PO
or
customer
can
easily
understands
the
test

•  Not
vague,
so
that
it
is
clear
exactly
what
condi;ons
make

the
test
pass
or
fail

•  Just
the
right
amount
of
detail,
concrete
data
relevant
to
the

scenario,
but
no
extra

•  Not
overly
technical

•  Not
scripty
(no
click
here,
etc.)

•  Let's
see
some
examples


16

Too
Vague


17

Scenario: Book search
When I search for a book
Then I expect to see the appropriate information
What
type
of
search:
by

Author,
ISBN,
Title?

Successful
or

failed
search?

What
data
are
we
using

to
search
with?

What
is
the
appropriate

informa;on
we
should

see:
speciﬁc
Author,
ISBN

or
Title?

Too
Technical


18

Scenario: Successful book search by author
Given the following Authors:
| id | name |
| 1 | Jeff Morgan |
| 2 | Gojko Adzic |
| 3 | Matt Wynne |
And the following Titles:
| id | title | author_id |
| 1 | Cucumber & Cheese | 1 |
| 2 | The Cucumber Book | 3 |
| 3 | Specification by Example | 2 |
And I'm on "http://www.mybooks.example/"
When I fill in "Morgan" in "//input[name()='query']"
And I click "#seekButton"
Then there should be 1 "div.book div.title" element
And the page should contain "Cucumber & Cheese"

Crea;ng
BDD
Acceptance
Scenarios

•  User
Stories,
especially
those
created
though
story
mapping,

are
a
good
place
to
start
talking
about
acceptance
criteria

•  That
can
lead
to
thinking
about
categories
of
test
scenarios

(test
;tles)

•  Given,
When,
Then

comes
next

•  Make
sure
there
is
concrete
test
data

•  Let's
see
how
it
works


22

In
order
to
conduct
banking

when
the
bank
is
closed

As
a
bank
customer

I
want
to
use
an
ATM

Why?

Who?

What?

Why
does
your

user
want
this?

Your
idea
probably
needs
to
be
broken
down
into
smaller
stories.

Who
is
this
user?

How
is
he/she

diﬀerent
from
other

users.

What
exactly
does

your
user
want?

Start
with
an
idea
for
an
App
(like
ATM
banking)

These
ideas
are
called
User
Stories.


23

Sample
ATM
Stories
(Features)

Cash
Withdrawal
:

In
order
to
get
money

when
the
bank
is
closed

As
a
bank
customer

I
want
to
withdraw
cash
at
the
ATM

Check
Deposit
:

In
order
to
deposit
my
checks

when
the
bank
is
closed

As
a
bank
customer

I
want
to
deposit
checks
at
the
ATM

Transfer
to
Savings:

In
order
to
earn
interest
even

when
the
bank
is
closed

As
a
bank
customer

I
want
to
transfer
money
from

checking
to
savings
at
the
ATM

Transfer
to
Checking:

In
order
to
not
overdraw
my
account

when
the
bank
is
closed

As
a
bank
customer

I
want
to
transfer
money
from
savings

to
checking
at
the
ATM


24

Choose
a
Story
(Feature)

(to
become
an
automated
test)

In
order
to
get
money

when
the
bank
is
closed

As
a
bank
customer

I
want
to
withdraw
cash
at
the
ATM

Feature: Cash Withdrawal
In order to get money when the
bank is closed
As a bank customer
I want to withdraw cash at the ATM

25

Acceptance
Criteria
will
become
our
specs

(test
scenarios)
when
they
have
details

Feature: Cash Withdrawal
In order to get money when the
bank is closed
As a bank customer
I want to withdraw cash at the ATM
• 
Successful
Withdrawal

• 

Less
than
balance

• 

Equal
to
balance

• 
Withdrawal
Failed
Due
to

Insuﬃcient
Funds

• 
Withdrawal
Failed
Because

Cash
Dispenser
Doesn’t

Dispense
One
Dollar
Bills

• 
Withdrawal
Failed
Because

Account
Closed

First
Cut
Acceptance
Criteria
for
several
tests


26

• 
Successful
Withdrawal

Given
my
account
has
been
credited

with
$100

When
I
withdraw
$20

Then

$20
should
be
dispensed

And
the
balance
of
my
account

should
be
$80

Choose
a
Scenario
and

Deﬁne
the
Steps
in
Testable
Detail


27

• 
Successful
Withdrawal

(less
than
balance)

Given my account has
starting balance of $100
When I withdraw $20
Then $20 should be
dispensed
And the ending balance of
my account should be $80
Given,
When,
Then
format
–

Business
language
with
unambiguous
detail

Detailed
Acceptance
Criteria

These
detailed
acceptance
criteria
are

acceptance
tests
that
are
executable
specs


28

With
Minor
Changes
it
can
become
an

Automated
Test
(Cucumber's
Gherkin)

• 
Successful
Withdrawal

Given
my
account
has
been

credited
with
$100

When
I
withdraw
$20

Then
$20
should
be
dispensed

And
the
balance
of
my
account

should
be
$80

Scenario: Successful Withdrawal
Given my account has been
credited with $100
When I withdraw $20
Then $20 should be dispensed
And the balance of my account
should be $80

29

The
Structure
of

Cucumber
Features

Feature: [ feature title ]
As a user [ role ]
I want [ feature ]
So that [ business value ]
Scenario: [ scenario title ]
Given [ a pre-condition ]
And [another pre-condition ]
When [ event ]
Then [ post-condition outcome ]
And [ another post-condition outcome ]
Plain

Text
Key

Words

From

User

Story

Ref:
Cucumber
code
examples
from

“The
Cucumber
Book”
by
MaS
Wynne
and
Aslak
Hellesøy


30

Example

Cucumber
Feature


31

Step
Deﬁni;ons


32

Cucumber
Command
Line


33

Plus
the
Evolving
Code
Under
Test

(Ruby
example,
code
could
be
in
any
language)


34

• 
Successful
Withdrawal

(equal
to
balance)

When I withdraw $100
Then $100 should be
dispensed
Add
More
Scenarios


35

When I withdraw $120
Then $0 should be
dispensed
And I should see a message
containing "insufficient
funds"
• 
Failed
Withdrawal

(insuﬃcient
funds)

Features

Scenarios

Automa;on
Libraries

(e.g.
rspec,
page-‐object,

wa;r-‐webdriver,
etc.)

Support
Code

(e.g.
env.rb,
hooks.rb,
Gemfile,

your
custom
page
objects)

Business

Facing

Technology

Facing


36

Step
Defini;ons

Cucumber/PageObject
Technology
Stack

Gherkin

(English-‐like

business

language)

Built-‐in
Ruby

Libraries
for

Tes;ng

Ruby

(oUen
modified

templates)

Steps
wriSen
in

Ruby

Steps

•  Testers
learn
the
business
side
of
BDD
quickly,
but
oUen
are

challenged
by
technology
side

•  Testers
add
important
perspec;ve
in
three
amigos
sessions

•  Make
sure
that
the
PO/customer
approves
of
the
scenario

wording
and
any
changes
to
it
(needs
to
readable
to
PO)

•  Testers
responsible
for
wri;ng
all
acceptance
tests

•  Testers
can
learn
technology
side
of
BDD.
Business
needs
to

provide
training,
coaching
and
pa;ence
(see
my
talk

"Growing
Manual
Testers
into
Automators")

•  Pair
Testers
and
Developers
to
speed
learning
technology

side


37

Teams
with
Tradi;onal
Manual
Testers

Teams
of
Only
Developers

•  Devs
learn
the
technology
side
of
BDD
quickly,
but
oUen
are

challenged
by
business
side

•  Developers
tend
to
think
"happy
path",
so
have
another
dev

or
BA
take
the
role
of
"devil's
advocate"
in
three
amigos

session
too
ﬂesh
out
error
scenarios

•  Make
sure
that
the
PO/customer
approves
of
the
scenario

wording
and
any
changes
to
it
(needs
to
readable
to
PO)

•  Developers
responsible
for
wri;ng
all
acceptance
tests

•  BDD
tests
do
NOT
take
the
place
of
TDD
unit
tests,
TDD
unit

tes;ng


38

Mob
Programming

•  Whole
team
works
together

•  On
the
same
thing

•  At
the
same
;me

•  In
the
same
space

•  Using
the
same
computer

•  Driver
rotates

•  Everyone
par;cipates

•  Great
for
training
&
prac;ce

•  Great
for
collabora;on

•  Everyone
up
to
speed
faster

•  Some
teams
mob
always,
others
frequently

•  Features
delivered
faster
–
single
piece
ﬂow
/wo
handoﬀs


39

Some
Tes;ng
Shouldn't
Be
Automated

•  Look
and
Feel
–
Does
the
corporate
logo
look
right?

•  Usability
–
Is
the
app
easy
to
use?

•  Page
Layout
of
PDF
documents
–
Easier
for
a
human
to

inspect

•  Readability
–
Humans
must
verify
readability

•  Transla;on
–
Does
the
Spanish
page
say
the
same
thing
the

English
page
does?

•  Data
Input
Integrity
(garbage
in/garbage
out)

•  Legalese
–
Some;mes
a
lawyer
must
verify
the
page
text

(unless
lawyer
is
part
of
the
Amigos
session)


40

BDD
&
TDD
Stoplight
Demo

Resources

and

References

Resources
–
BDD
Overview
and
Value

•  How
tests
become
Executable
Speciﬁca;ons
–
Explains
without

coding,
also
good
overview
for
anyone

–  Speciﬁca$on
by
Example:
How
Successful
Teams
Deliver

the
Right
So+ware
by
Gojko
Adzic


43

Available
from
Amazon
or
Manning
hSps://www.manning.com/

Managers,
Requirements
Analysts,
Product
Owners
and
others

who
want
to
understand
the
concepts,
human
interac$ons
and

value
of
BDD
/
ATDD

Resources
–
Cucumber
Books

Ignore
references
to
headless
Rails
tes$ng
unless
using
Rails

•  Cucumber
with
Ruby
–
General

–  The
Cucumber
Book:
Behavior-‐Driven
Development
for

Testers
and
Developers
by
MaS
Wynne
&
Aslak
Hellesoy

•  Advanced
Cucumber
Topics

–  Cucumber
Recipes:
Automate
Anything
with
BDD
Tools

and
Techniques
by
Ian
Dees,
MaS
Wynne
&
Aslak
Hellesøy


44

Available
from
Amazon
or
the
Pragma;c
Bookstore
hSps://pragprog.com/

Resources
–
Free
Cucumber
Info

Cucumber
Wikis

•  Both
wikis
focus
on
headless
Cucumber
(not
in
browser
with

PageObject),
but
provide
useful
info
on
Cucumber
and
Gherkin

•  Older
Wiki
–
easy
to
explore
format,
contains
some
info
not
in

new
wiki
hSps://github.com/cucumber/cucumber/wiki

•  Newer
Wiki
–
contains
some
nice
blogs
and
plug
for
semi

commercial
product
and
support
hSps://cucumber.io/


45

Resources
–
Free
Ruby
Info

Ruby
101
–
the
basics:
(Learn
Ruby

2.x
not
Ruby
1.9)

•  On-‐line
tutorials
–
my
favorite
is

Ruby
Monk

hSps://rubymonk.com

Learn
to
navigate
the
documenta$on:

•  Ruby's
built-‐in
classes
and
methods

are
very
rich.

•  Testers
should
learn
to
check
if
the

needed
func;onality
already
exists

•  Ruby
docs
are
found
at

hSp://ruby-‐doc.org/


46

ALL

SOME

Resources
–
Cheezy's
Book

Cucumber
with
PageObject
–
Best
approach
to
web
tes$ng
(IHMO)

•  Covers
Cucumber,
Gherkin,
PageObject,
Wa;r,
Selenium,
etc.
used
in

web
demo

•  Step
by
step
tutorial
with
exercises

•  SoUcopy
only,
work
in
progress,
updated
periodically

–  Cucumber
and
Cheese:
A
Testers
Workshop
by
Jeﬀ
Morgan


47

Available
only
from
Lean
Pub
hSps://leanpub.com/cucumber_and_cheese

Resources
–
Free
PageObject
Info

Cheezy's
(Jeﬀ
Morgan's)
Blog

•  Other
Cheezy
blog
posts
are
also

worthwhile

hSp://www.cheezyworld.com/
2011/07/29/introducing-‐page-‐
object-‐gem/

Oﬃcial
documenta$on

•  PageObject
is
a
gem.

•  Like
most
gems,
it
and
its

documenta;on
can
be
found
on

GitHub
(scroll
down)

hSps://github.com/cheezy/page-‐
object


48

Resources
–
Free
Detailed
Demo

Cheezy's
Demo
Tes$ng
Puppies
Site

•  Uses
RubyMine
IDE,
but
other

editors
or
IDEs
work
ﬁne

•  Covers
a
later
example
from

Cucumber
and
Cheese
book
resource

•  1
hour
10
minute
YouTube
video

hSps://www.youtube.com/watch?
v=zpt15XIjpas


49

Resources
–
Ruby
Books

If
Ruby
Monk
is
too
challenging,
try
Learn
to
Program

•  For
those
who
haven't
programmed
before
(most
manual

testers)

–  Learn
to
Program
-‐
Second
Edi$on
by
Chris
Pine

•  For
those
who
know
object-‐oriented
programming
in
some

other
language
(includes
more
Ruby
than
most
testers
will

need)

–  Programming
Ruby
1.9
&
2.0
by
Dave
Thomas

•  For
a
problem-‐based
approach
to
wri;ng
small
pieces
of

Ruby
that
do
useful
things

–  Everyday
Scrip$ng
with
Ruby
by
Brian
Marick


50

Available
from
Amazon
or
the
Pragma;c
Bookstore
hSps://pragprog.com/

Camille
Bell

Agile
Technical
&
Process
Coaching

Retrospec;ves

Agile
Boot
Camps

Agile
Training

Updated
Slides

or
just
to
chat
about
things
agile


Twi2er
@agilecamille

Inside Behavior Driven Development

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Inside Behavior Driven Development

Similar to Inside Behavior Driven Development (20)

More from Camille Bell

More from Camille Bell (7)

Recently uploaded

Recently uploaded (20)

Inside Behavior Driven Development