BDD & JBehave emphasize behavior over testing by describing features in plain language from the business perspective. It improves on TDD by making tests more readable and meaningful. Behavior is described using a Given-When-Then format in executable specifications called examples or stories. BDD brings business analysts, developers and testers together with a shared ubiquitous language to specify requirements and automate acceptance tests.

1. BDD & JBehave
emphasize behavior over testing

3. right software
software right
unmaintainable
business
failure
success
atomic
fail!
problem

4. introduction
Dan North
want to
improve TDD
a unit test
is more meaningful
in a full sentence
should_login_a_user_to_his_account() {}
Behavior
is also described
by Business Analysts
Eric Evens:
ubiquitous language
Chris Matts
The Business Analyst GOAL:
readable requirements
and automated
acceptance tests
GIVEN
WHEN
THEN

5. principles
Business Goal Stories
Examples
Executable Spec
Low Level Specification

6. principles
Business Goal Stories
Examples
Executable Spec
Low Level Specification
user
stakeholder
business analyst

7. principles
Business Goal Stories
Examples
Low Level Specification
user
stakeholder
business analyst
developer
tester
ops
user
stakeholder
business analyst
Executable Spec

8. BDD
TDD
Failing
Acceptance Test
Failing Unit Test
Test Pass
Refactor
BDD and TDD
Acceptance
Pass

10. write a Story
Title
Narrative:
As a [role]
I want [feature]
So that [benefit]
Scenario 1: Title
Given [context]
And [some more context]...
When [event]
Then [outcome]
And [another outcome]...
Scenario 2: ...
Title: A customer should add items to his cart
Narrative:
As a customer
I want to add items to my shopping cart
So that I can place an new order
Scenario: Customer should add an item
to shopping cart
Given a shopping cart
When a customer adds an item to his shopping cart
Then the shopping cart contains 1 different item

12. now JBehave

13. make the specification executable

14. at a glance
Pros
• reduces waste
• changes are saver
• spread the knowledge
• brings the team together
• domain language
• find design smells
• serves as documentation
• (reduces costs)
Keep in mind
• high business engagement
• don’t use with design up front
• won’t work in silos
• bad tests lead to bad code

17. bibliography
Books
BDD in Action
Growing Object-Oriented Software, Guided by Tests
Specification By Example
ATDD By Example
Online
http://dannorth.net/whats-in-a-story/
https://weblogs.java.net/blog/manningpubs/archive/2013/06/10/introducing-behavior-driven-development
http://technologyconversations.com/category/behavior-driven-development-bdd/
http://www.thoughtworks.com/insights/blog/qa-role-what-it-really
http://www.jbehave.org