Your SlideShare is downloading. ×

Introduction to Behaviour Driven Development

2,968

Published on

A short introduction to Behaviour Driven Development.

A short introduction to Behaviour Driven Development.

0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,968
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
140
Comments
0
Likes
5
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Own experience: unclear specs!Valid also for ”traditional teams”, though made clearer for agile teamsBehaviour-driven development (BDD) takes the position that you can turn an idea for a requirement into implemented, tested, production-ready code simply and effectively, as long as the requirement is specific enough that everyone knows what’s going on
  • This, then, is the role of a Story. It has to be a description of a requirement and its business benefit, and a set of criteria by which we all agree that it is “done”. This is a more rigorous definition than in other agile methodologies, where it is variously described as a “promise of a conversation” or a “description of a feature”. (A BDD story can just as easily describe a non-functional requirement, as long as the work can be scoped, estimated and agreed on.)
  • Transcript

    • 1. BDD
      Behaviour Driven Development (BDD)
      The 10 minutes Introduction
      Christophe Achouiantz – June 2011
    • 2. The need for BDD
      Most common impediment for an agile team:
      Unclear Specifications!
      Christophe Achouiantz – June 2011
      2011-06-22
      Sida 2
    • 3. BDD
      2006 – Dan North
      ”TDD/ATDD done well”
      “TDD will cause me to have lots of tests, but it won’t necessarily get me nearer the goal of delivering business value through software.”
      Test Driven Development – TDD
      Acceptance Test Driven Developement -ATDD
      2011-06-22
      Sida 3
      Christophe Achouiantz – June 2011
    • 4. BDD is about Business Value
      Behaviour
      Driven
      Development
      2011-06-22
      Sida 4
      Christophe Achouiantz – June 2011
    • 5. An ”Outside-in” methodology
      BDD is an “outside-in” methodology.
      Starts at the outside by identifying business outcomes,
      and then drills down into the feature set that will achieve those outcomes.
      2011-06-22
      Sida 5
      Christophe Achouiantz – June 2011
    • 6. The Core of BDD: the ”Story”
      Each feature is captured as a “story”, which defines the scope of the feature along with its acceptance criteria.
      BDD ”Story” =
      Narative (User Story) +
      Acceptance Criteria (Scenarios)
      2011-06-22
      Sida 6
      Christophe Achouiantz – June 2011
    • 7. The Narative: User Stories
      User Story as narative (context)
      User centric
      Focus on What not so much How
      Contains sufficient information so that all stakeholders understand the context (who, when, what, why)
      2011-06-22
      Sida 7
      Christophe Achouiantz – June 2011
    • 8. The Narative: User Stories
      + Title of the Story +
      As a <role>,
      I want <feature>,
      So that <benefit>
      2011-06-22
      Sida 8
      Christophe Achouiantz – June 2011
    • 9. The Narative: User Stories
      + Customer withdraws cash +
      As a customer,
      I want to withdraw cash from an ATM,
      so that I don’t have to wait in line at the bank.
      2011-06-22
      Sida 9
      Christophe Achouiantz – June 2011
    • 10. The Acceptance Criteria: Scenarios
      A UserStory’sbehaviour is itsacceptancecriteria
      Acceptancecriteriadefine the scope of the narative/behaviour
      Acceptance criteria gives us a shared definition of “done”
      2011-06-22
      Sida 10
      Christophe Achouiantz – June 2011
    • 11. The Acceptance Criteria: Scenarios
      + Scenario Title +
      Given <context>,
      When <event>,
      Then <outcome>
      2011-06-22
      Sida 11
      Christophe Achouiantz – June 2011
    • 12. The Acceptance Criteria: Scenarios
      +Scenario 1: Account is in credit+
      Given the account is in credit
      And the card is valid
      And the dispenser contains cash,
      When the customer requests cash,
      Then ensure the account is debited
      And ensure cash is dispensed
      And ensure the card is returned.
      2011-06-22
      Sida 12
      Christophe Achouiantz – June 2011
    • 13. The Acceptance Criteria: Scenarios
      +Scenario 2: Account is overdrawn past the overdraft limit+
      Given the account is overdrawn
      And the card is valid,
      When the customer requests cash,
      Then ensure a rejection message is displayed
      And ensure cash is not dispensed
      And ensure the card is returned.
      2011-06-22
      Sida 13
      Christophe Achouiantz – June 2011
    • 14. The Power of Scenarios
      Scenarios
      =
      Test Cases
      =
      Acceptance Criteria
      2011-06-22
      Sida 14
      Christophe Achouiantz – June 2011
    • 15. A Good Story
      The title should describe an activity
      The narrative should include a role, a feature and a benefit
      The scenario title should say what’s different
      The scenario should be described in terms of Givens, Events and Outcomes
      The givens should define all of, and no more than, the required contextThe event should describe the feature
      The story should be small enough to fit in an iteration
      2011-06-22
      Sida 15
      Christophe Achouiantz – June 2011
    • 16. Effect of BDD: A Specification and Ubiquitous Language
      BDD Story
      Great for discussing with customer, end-users, other stakeholders
      Great for coding, testing, validation
      = Specification (by example)
      + Promotes an Ubiquitous Language (everyone speaks the same language!)
      2011-06-22
      Sida 16
      Christophe Achouiantz – June 2011
    • 17. BDD is relying on Examples
      ”Specification by Example”
      Examples tell a story about what the system does
      Gojko Adzic
      By the way:
      TDD is then more ”Coding by Example”
      Examples tell a story about what the code does
      2011-06-22
      Sida 17
      Christophe Achouiantz – June 2011
    • 18. BDD in Practice
      Better requirements workshops / User Stories writing workshops
      Iterative work – clarify requirements:
      Write user story + scenarios
      Re-write user story (break down?)+ scenarios
      Helps to understand ”What do we want?”
      ”Aha!” reaction from participants
      Helps to write clear, concrete requirements
      2011-06-22
      Sida 18
      Christophe Achouiantz – June 2011
    • 19. BDD Tools
      Automate your Scenarios!
      Frameworks for:
      Java - JBehave
      .Net - SpecFlow
      Ruby – Cucumber
      Others…
      2011-06-22
      Sida 19
      Christophe Achouiantz – June 2011
    • 20. BDD Tools: Cucumber (Ruby)
      2011-06-22
      Sida 20
      Christophe Achouiantz – June 2011
    • 21. Starting with BDD
      Use Scenarios during your next requirement writing workshop!
      2011-06-22
      Sida 21
      Christophe Achouiantz – June 2011
    • 22. Happy BDD!
      2011-06-22
      Sida 22
      Christophe Achouiantz – June 2011

    ×