BDD is an agile methodology that focuses on defining desired software behaviors and outcomes through user stories and scenarios. Stories are written collaboratively with stakeholders using a ubiquitous language. Teams practice outside-in development by writing automated tests derived from stories before writing code. Stories are pulled from a prioritized backlog for development in short iterations. Automated tests provide feedback and documentation. Reports are generated for stakeholders.

1. Introduction to Behavior Driven
Development for Java Developers
Gordon Force
January 10, 2012
January 10, 2012

2. What is Behavior Driven Development (BDD)?
What is Behavior Driven Development (BDD)?
Short Definition
Short Definition
“Behaviour‐driven development is about implementing an
application by describing its behaviour from the
perspective of its stakeholders” – Dan North
A Bit More Complete
A Bit More Complete
"a second‐generation, outside–in, pull‐based, multiple‐
stakeholder, multiple‐scale, high‐automation, agile
, p , g , g
methodology. It describes a cycle of interactions with well‐
defined outputs, resulting in the delivery of working,
tested software that matters.
tested software that matters " – Dan North
Dan North

3. Second Generation Built On …
Second Generation Built On …
User Stories
User Stories
eXtreme Programming (XP)
eXtreme Programming (XP)
– Test Driven Development
–AAcceptance Driven Test Planning
t Di T t Pl i
– Continuous Integration (Automation)
Domain‐Driven Design

4. Outside‐In Methodology
Outside In Methodology
Stories describe
Stories describe
features from the
stakeholders POV
Development
delivers
Runnable Tested
Runnable Tested
Features aka
software that
matters

5. BDD Stories
BDD Stories

6. Multiple Stakeholder
Multiple‐Stakeholder
• Multiple stakeholders (should) define an application’s behavior
• Each stakeholder represents one or more business domains
– Each domain uses a particular jargon or domain language
• Stakeholders involvement for OnPay Story Content
– Product: customer interactions, payments knowledge, SLAs
– Sales: sales programs (discounts), negotiating SLAs
Sales: sales programs (discounts) negotiating SLAs
– Accounting: reconciliation, booking revenue, SOX & SAS‐70 compliance
– Security: authentication, encryption, web‐attacks, other PCI compliance items
– Data Center: app monitoring, patching , system capacity, other ITIL funcs
Data Center: app monitoring patching system capacity other ITIL funcs
– Legal: user agreements, fee language, SLA agreements
– Customer Support: call support performance, support tool effectiveness
– Web Design: website appearance (UI Widgets) and usability
Web Design: website appearance (UI Widgets) and usability

7. User Stories Overview
User Stories Overview
• Created a planning tool
Created a planning tool
– Must have a business value
– Must be testable
Must be testable
– Small enough to fit in a sprint / iteration
• E h i
Emphasizes conversations over specifications
ti ifi ti
• Narrative describes a feature
– One or more stories can describe a feature
• Acceptance Criteria defines doneness
p

8. The Team Writes the Story
The Team Writes the Story
• SHs describe features & outcomes in the 1st draft
SHs describe features & outcomes in the 1
• All work together to complete the story
– Express interactions between domain objects as well
Express interactions between domain objects as well
defined and verifiable behaviors
– Blend terms from multiple domains to create a
ubiquitous language used by the team to write the
story.
– Leverage expertise within the team
h h
• QA identifies testable contexts, Dev estimates the scope,
Web Design maps user interaction onto UI elements
g p

9. BDD Story Format
BDD Story Format
Title (one line describing the story)
Narrative: • Described as a User Story
In order to [benefit] • Uses a Ubiquitous Language (UL) developed by the team
As a [role] • Benefit is the rationale, might be testable
I want to [feature] • Should fit in an sprint, otherwise break up into smaller stories
Acceptance Criteria:
Scenario: Title • Describes outcomes for an event.
Given [context] • The event describes the feature
And [some more context]... • Must be testable
When [event] • Not always simple
Then [outcome]
[ ] • gp
Minimize domain mixing per scenario
And [another outcome]...
Scenario: ... • Describes another outcome for another event and context

10. P2P Send Money Story
P2P Send Money Story
Title (one line describing the story) Send P2P Money
Narrative: Narrative:
In order to [benefit] In order to spend less time paying my debts in person or by mail
As a [role] As a Person
I want to send money online to another Person
I want to send money online to another Person
I want to [feature]
Scenario: Payor has enough funds
Scenario: Title Given Bob is logged into his account page and has an available
Given [context] balance of $100
$
And [some more context]... When filling out the send money form with $90.01 in the amount
When [event] field, sue@localhost in the recipient field and clicking on the submit
Then [outcome] button
Then OnPay updates the account page with an available balance of
And [another outcome]...
[ ] $90 and a pending $10 transaction to sue@localhost
$90 and a pending $10 transaction to sue@localhost
And adds a payment notification to the account page for Sue in the
notifications section
Scenario: ...
Scenario: Scenario : Payor does not have enough funds
y g

11. Pull Based is better than Push Based
Pull Based is better than Push Based
• Pushing is imposed features & deadlines
us g s posed eatu es & dead es
– What we need is you to develop this by last week
• Pulling is more efficient and enables scaling
g g
– Stories are prioritized by business value.
• Clarifies relative importance
– The team commits to story delivery based on priority
and capacity
• Creating sub‐stories when required
g q
– With a deep backlog more than one team can help
– Pulling requires Outside In communication

12. The Pull Cycle
The Pull Cycle
• SHs add BV prioritized stories to the backlog
SHs add BV prioritized stories to the backlog.
• Dev pulls the highest priority stories to work
on that fit in a sprint.
on that fit in a sprint
• Dev demonstrates completed stories as
Runnable Tested Features (RTF) to SHs.
R bl T dF (RTF) SH
– RTF is software that matters.
• The business pulls a collection of RTFs to
release as an application or update.

13. High Automation: BDD Testing
High Automation: BDD Testing

14. The Red Green Refactor TDD Cycle
The Red‐Green‐Refactor TDD Cycle
1) Write a Test
First (fails)
jUnit,
TestNG
3) Refactor
2) Code Until
2) Code Until
Test Passes

15. BDD Testing is not Unit Testing
BDD Testing is not Unit Testing
• jUnit was written for developers
jUnit was written for developers
– Does a great job for object / unit testing
– Popularized “code by example” development
p y p p
• Cumbersome to adapt for story testing
– Test names are method names
Test names are method names
– Test runners assume one test per object lifetime
– jUnit reports use asserts and their stack traces to
j p
describe failures
• It takes a developer to understand what failed.

16. The BDD Cycle
The BDD Cycle
1) Focus on one
)
scenario
2) Write a failing step
definition
3) Write failing
example
5) Refactor
4) Get example
to pass
t
7) Refactor
6) Step Up when
jbehave, Example Passes
Example Passes
easyb

17. jbehave Overview
jbehave Overview
• Automates story testing
Automates story testing
– Parses stories written in text, ODT and Google Docs
– Executes stories synchronously or asynchronously
Executes stories synchronously or asynchronously
– Enables Outside‐In development
• Integrates with existing test runners
Integrates with existing test runners
– jUnit, TestNG, Spring Test
– Enables integrate with maven ant eclipse
Enables integrate with maven, ant, eclipse
• Emits stakeholder readable reports
– Supports custom templates
Supports custom templates

18. Remote Web Testing Client
Remote Web Testing Client
jbehave
Test Runner
Test Runner
steps stories
jUnit / Spring / TestNG
embedder story maps selenium
Test runner dependent
configuration classes firefox

19. Direct Testing Application
Direct Testing Application
jbehave
Test Runner
Test Runner
steps stories
jUnit / Spring / TestNG
application
embedder story maps
code
Test runner dependent
configuration classes

20. jbehave Usage
jbehave Usage
1. Write a Story
1 Write a Story
2. Configure Embedder and Story Mapper
– Li k t i
Links stories, steps and reports together
t d t t th
3. Implement steps using the BDD Cycle
– Annotations associate steps with methods
4. Run the story
5. View Generated Reports

21. Mapping Steps with Annotations
Mapping Steps with Annotations
package com.forceassociates.onpay_webtester.steps;
import
i org.jbehave.core.annotations.Given;
j i i
import org.jbehave.core.annotations.Then;
import org.jbehave.core.annotations.When;
import org.junit.Assert;
org junit Assert;
public class P2PSendMoneySteps {
@Given("$payor is logged into his account page")
public void loginToAccountPage(String payor) {
// Add code under test or
// Selenium client action here to carry out the step
}
}

22. Handling the Unexpected
Handling the Unexpected
• P2P Send Money Story needs registered users
P2P Send Money Story needs registered users
– Need additional stories describing registration
• How to handle with in an Agile project
How to handle with in an Agile project
– Review options with your team
– Focus on creating a story that matters
• Create missing stories & implement to cover gap
•M k i i
Mock missing services & data
i &d t
• Last resort is returning the story to the backlog

23. Register People Story
g p y
Narrative:
In order to use OnPay
As a Person
I want to register for OnPay
Scenario: Person Registers for OnPay
Given a browser is on the OnPay registration page
When filling out the registration form with <name> in the name field, <email> in the email
address field, <amount> in the initial funding field and clicking on the submit button
Then OnPay creates an account for <name> and displays their account page
Examples:
|name |email |amount |
|
|Bob|bob@localhost|$100|
| @ |$ |
|Sue |sue@localhost |$450|

24. Dependant Given Story for a Scenario
Dependant Given Story for a Scenario
P2P Send Money
Narrative:
In order to spend less time paying my debts in person or by mail
As a Person
I want to send money online to another Person
Scenario: Payor has enough funds
GivenStories: com/forceassociates/onpay_webtester/stories/RegisterPeople.given.txt
Given Bob is logged into his account page and has an available balance of $100
Bob is logged into his account page and has an available balance of $100
When filling out the send money form with $90.01 in the amount field, sue@localhost in the
recipient field and clicking on the submit button
Then OnPay updates the account page with an available balance of $90 and a pending $10
transaction to sue@localhost
And adds a payment notification to the account page for Sue in the notifications section

25. Invoking jbehave
Invoking jbehave
• Maven Plugin
Maven Plugin
– jbehave archetypes use integration‐test phase
• mvn integration‐test
– Very customizable
• Eclipse
– Execute as a jUnit test or using m2eclipse
• Example story report on the next two pages
l h

29. Other Testing Thoughts
Other Testing Thoughts
• Story tests are long lived
Story tests are long lived
– Should be used for regression tests
– Subset for used for build acceptance tests
– Must be kept up to date
• Testing Low Level Code
– Interactions bet een objects are beha iors
Interactions between objects are behaviors
– Can be done with either jBehave or jUnit

30. Restart the BDD Cycle
Restart the BDD Cycle
• Facilitate story development
Facilitate story development
– Provide a demo instance to SHs
– Mock out features not implemented yet
Mock out features not implemented yet

31. Bibliography
• Kent Beck
– Extreme Programming Explained (2nd Edition), Addison‐Wesley Professional, 2004
– Test Driven Development: By Example, Addison‐Wesley Professional, 2002
– Web: http://www.threeriversinstitute.org/blog/
• Mike Cohn
– Applied Users Stories: For Agile Software Development, Addison‐Wesley‐Professional, 2004
– Web: http://www.mountaingoatsoftware.com/topics/user‐stories
• Eric Evans
– Domain‐Driven Design: Tackling Complexity in the Heart of Software, Addison‐Wesley Professional, 2003
D i Di D i T kli C l i i h H fS f Addi W l P f i l 2003
– Web: http://domaindrivendesign.org/
• Dan North
– The RSpec Book: Behaviour Driven Development with Rspec, Cucumber, and Friends, Pragmatic Bookshelf, 2010
The RSpec Book: Behaviour Driven Development with Rspec Cucumber and Friends Pragmatic Bookshelf 2010
– Web: http://dannorth.net/ http://behaviour‐driven.org/BehaviourDrivenDevelopment
http://www.slideshare.net/skillsmatter/bdd‐introduction
– jBehave: http://jbehave.org/

32. Presenter Information
Presenter Information
Gordon Force Jr.
Gordon Force Jr
Principal at Force Associates
Email: gordon@force‐associates.com
Email gordon@force associates com
Twitter: @forceassociates
Example source code: https://github.com/gordon force
Example source code: https://github com/gordon‐force‐
associates/onpay‐webtester