Downloaded 206 times
Uploaded byChristophe Achouiantz
Introduction to Behaviour Driven Development
BDD (Behaviour Driven Development) is an outside-in development methodology that starts with identifying business outcomes. Each feature is captured as a story containing a narrative user story and acceptance criteria in the form of scenarios. Scenarios define the scope of the user story and provide shared acceptance criteria. BDD promotes the use of examples and scenarios to specify requirements, drive development, and validate software delivers expected business value.
More Related Content
Similar to Introduction to Behaviour Driven Development
Introduction to Behaviour Driven Development
- 1. BDDBehaviour Driven Development(BDD)The 10 minutes IntroductionChristophe Achouiantz – June 2011
- 2. The need forBDDMost common impediment for an agile team:Unclear Specifications!Christophe Achouiantz – June 20112011-06-22Sida 2
- 3. BDD2006 – DanNorth”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 – TDDAcceptance Test Driven Developement -ATDD2011-06-22Sida 3Christophe Achouiantz – June 2011
- 4. BDD is aboutBusiness ValueBehaviourDrivenDevelopment2011-06-22Sida 4Christophe Achouiantz – June 2011
- 5. An ”Outside-in” methodologyBDDis 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-22Sida 5Christophe Achouiantz – June 2011
- 6. The Core ofBDD: 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-22Sida 6Christophe Achouiantz – June 2011
- 7. The Narative: UserStoriesUser Story as narative (context)User centricFocus on What not so much HowContains sufficient information so that all stakeholders understand the context (who, when, what, why)2011-06-22Sida 7Christophe Achouiantz – June 2011
- 8. The Narative: UserStories+ Title of the Story +As a <role>,I want <feature>,So that <benefit>2011-06-22Sida 8Christophe Achouiantz – June 2011
- 9. The Narative: UserStories+ 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-22Sida 9Christophe Achouiantz – June 2011
- 10. The Acceptance Criteria:ScenariosA UserStory’sbehaviour is itsacceptancecriteriaAcceptancecriteriadefine the scope of the narative/behaviourAcceptance criteria gives us a shared definition of “done”2011-06-22Sida 10Christophe Achouiantz – June 2011
- 11. The Acceptance Criteria:Scenarios+ Scenario Title +Given <context>,When <event>,Then <outcome>2011-06-22Sida 11Christophe Achouiantz – June 2011
- 12. The Acceptance Criteria:Scenarios+Scenario 1: Account is in credit+Given the account is in creditAnd the card is validAnd the dispenser contains cash,When the customer requests cash,Then ensure the account is debitedAnd ensure cash is dispensedAnd ensure the card is returned.2011-06-22Sida 12Christophe Achouiantz – June 2011
- 13. The Acceptance Criteria:Scenarios+Scenario 2: Account is overdrawn past the overdraft limit+Given the account is overdrawnAnd the card is valid,When the customer requests cash,Then ensure a rejection message is displayedAnd ensure cash is not dispensedAnd ensure the card is returned.2011-06-22Sida 13Christophe Achouiantz – June 2011
- 14. The Power ofScenariosScenarios=Test Cases=Acceptance Criteria2011-06-22Sida 14Christophe Achouiantz – June 2011
- 15. A Good StoryThetitle should describe an activityThe narrative should include a role, a feature and a benefitThe scenario title should say what’s differentThe scenario should be described in terms of Givens, Events and OutcomesThe givens should define all of, and no more than, the required contextThe event should describe the featureThe story should be small enough to fit in an iteration2011-06-22Sida 15Christophe Achouiantz – June 2011
- 16. Effect of BDD:A Specification and Ubiquitous LanguageBDD StoryGreat for discussing with customer, end-users, other stakeholdersGreat for coding, testing, validation= Specification (by example)+ Promotes an Ubiquitous Language (everyone speaks the same language!)2011-06-22Sida 16Christophe Achouiantz – June 2011
- 17. BDD is relyingon Examples”Specification by Example”Examples tell a story about what the system doesGojko AdzicBy the way:TDD is then more ”Coding by Example”Examples tell a story about what the code does2011-06-22Sida 17Christophe Achouiantz – June 2011
- 18. BDD in PracticeBetterrequirements workshops / User Stories writing workshopsIterative work – clarify requirements:Write user story + scenariosRe-write user story (break down?)+ scenariosHelps to understand ”What do we want?””Aha!” reaction from participants Helps to write clear, concrete requirements2011-06-22Sida 18Christophe Achouiantz – June 2011
- 19. BDD ToolsAutomate yourScenarios!Frameworks for:Java - JBehave.Net - SpecFlowRuby – CucumberOthers…2011-06-22Sida 19Christophe Achouiantz – June 2011
- 20. BDD Tools: Cucumber(Ruby)2011-06-22Sida 20Christophe Achouiantz – June 2011
- 21. Starting with BDDUseScenarios during your next requirement writing workshop!2011-06-22Sida 21Christophe Achouiantz – June 2011
- 22. Happy BDD!2011-06-22Sida 22ChristopheAchouiantz – June 2011
Editor's Notes
- #3 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
- #7 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.)