Introduction to Behaviour Driven Development
•Télécharger en tant que PPTX, PDF•
8 j'aime•3,803 vues
A short introduction to Behaviour Driven Development.
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Introduction to Behaviour Driven Development
Similaire à Introduction to Behaviour Driven Development (20)
Plus de Christophe Achouiantz
Plus de Christophe Achouiantz (16)
Dernier
Dernier (20)
Introduction to Behaviour Driven Development
- 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
Notes de l'éditeur
- 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.)