This document introduces Behavior Driven Development (BDD) as a rethinking and repurposing of existing agile methodologies like test-driven development (TDD) and extreme programming (XP) with a focus on defining value upfront. It discusses how BDD uses features made up of scenarios in a given-when-then format to define required system behaviors. This drives the development process through a red-green-refactor cycle of writing failing acceptance tests, unit tests, and code to pass the tests. The document recommends BDD tools like FitNesse, Story Q, and Cucumber and emphasizes that BDD is not about tools but rather delivering value through defined behaviors.

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

2. 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

3. 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

4. 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)

5. 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

6. Features
(come from agile
stories)

7. 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

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

9. 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

10. 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

11. 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

12. 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

13. 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

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

15. ATDD* Tools
*Acceptance Test Driven Design

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

17. • 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

18. Story Q
Nunit Based Runner for
Stories

19. 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

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

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

22. Unit Testing

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

24. 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

25. 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

26. 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

27. 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

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