Introduction to Behaviour Driven Development


Published on

A short introduction to Behaviour Driven Development.

  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

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.)
  • Introduction to Behaviour Driven Development

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