Behaviour Driven
Development
owen evans, xero.com developer
http://bgeek.net @buildmaster

Behaviour Driven
Development
• What is BDD?
• A rethinking and repurposing of
existing methodologies
• A second generation Agile Technique
• A companion to other techniques
such as TDD and XP

A Combination of
Disciplines
• TDD
• Test first methodology
• But a focus on value
• Defining value up front
• XP/Scrum/<Insert ‘Agile’ methodology here>
• Close communication with all stakeholders
• Common language definition to aid
communication

A Focus On Value
• TDD says only one thing: Test First
• Tests alone do not drive value
• Tests are not deliverables
• Tests can be crap
• BDD says: only do what needs to be
done (and test first)

What needs to be done?
• Test driven specification/Acceptance
Test Driven Design
• All systems can be defined by their
behaviour [says BDD]
• The behaviour is what makes a system
usable/crap
• We can use required behaviour to
drive development

Features
(come from agile
stories)

Example: STEP ONE THE
Feature
Feature
As a Cake Lover
I want to be able to turn on my Acme
Cake Maker
So that I can start making great cakes

The Feature
• Broken into three elements:
• the actor (Cake Lover)
• the action (turn on cake maker)
• the motivation (want to start making
cakes)

Why?
• The actor gives us a stakeholder, this is
who we’re providing value to
• The action allows us to drive
functionality
• The motivation allows us to tell when
we’re done

Example part 2: The
Scenario(s)
Scenario
Given there the cake maker is not switched
on
When I press the “on” button
Then the machine should say “welcome to
the Acme Cake Maker”
And the machine should ask me which cake
type I want to make

Scenarios
• Scenarios are always 1st person
• We want to design in terms of the
stakeholder
• We want to see that we are providing
them value

What does this give us?
• BDD has three main tenants:
• Enough is Enough
• Just do what’s needed no more
• Deliver Stakeholder Value
• Everything we do should be tracable to
value to a stakeholder
• It’s All Behaviour
• We can alwys describe code in terms of it’s
behaviours

Remember
• A stakeholder isn’t necessarily a human
• it can be a company goal
• it can be required API’s
• it can be other developers (ok they
might be human)
• Stakeholder ≠ customer

Great... WTF?
• How do we apply this
• BDD has inspired many tools

ATDD* Tools
*Acceptance Test Driven Design

FitNesse
Granddaddy of
Acceptance Testing
Tools.
A wiki formed around
Ward Cunningham’s
Framework for
Integrated Testing (FIT)

• Pros:
• Language agnostic (runners for most major
languages)
• Wiki Syntax is easy to learn and use
• Cons:
• Doesn’t support BDD syntax easily/natively
• Fit style tests can be quite cumbersome
when setting up complex objects

Story Q
Nunit Based Runner for
Stories

Story Q
• Pros:
• native c#
• native support for BDD
• quick integration with
testing tools
• Cons
• Code based (only
output is stakeholder
readable)
• Syntax can be hard

Cucumber
A Ruby BDD
Specification Runner
Part of the RSpec Ruby
Testing Framework

• Pros:
• Feature rich
• Native support for BDD syntax
• Plain text runner (sharable
specifications)
• Cons:
• Ruby only

Unit Testing

• Keep to your framework of choice
• Xunit.net
• Nunit
• MBUnit
• also many frameworks to help use a more
BDD syntax
• NBehave, NSpecify,
Machine.Specifications

How does this all fit
together
• Concentric feedback circles:
• Step 1 write the acceptance test(s) using Given
When Then syntax
• Step 2: Make sure they fail (red-green-refactor
cycle)
• Step 3: Write unit test on first part of code (this is
just TDD), and make sure it fails
• Step 4: Make test pass, does Acceptance test pass?
• Yes go to step 1, No go to step 3

In Pictures
Focus on one scenario
1. Write Failing step definition
drop into unit tests
2. Write failing unit test
3. Get the test to pass
4. Refactor
5. Once Acceptance Test Step is passing
6. Refactor
7. Repeat 2-6 till acceptance test is
complete and passes
Write next acceptance test

Take aways
• BDD is not about tooling
• BDD focuses on three tenants
• Enough is Enough
• Always deliver value
• Everything can be expressed as
behaviour
• BDD is only part of the arsenal

Great resources
• Cucumber and RSpec are thought
leading frameworks so read the RSpec
Book
• http://www.pragprog.com/titles/
achbd/the-rspec-book
• BDD mailing list
• http://groups.google.com/group/
behaviordrivendevelopment

FIN
me: owen@bgeek.net
Twitter: @Buildmaster
Blog: http://bgeek.net