Recommandé
Contenu connexe
Similaire à Introduction to BDD for Java with jBehave
Similaire à Introduction to BDD for Java with jBehave (20)
Plus de Marakana Inc.
Plus de Marakana Inc. (20)
Dernier
Dernier (20)
Introduction to BDD for Java with jBehave
- 1. Introduction to Behavior Driven Development for Java Developers Gordon Force January 10, 2012 January 10, 2012
- 2. What is Behavior Driven Development (BDD)? What is Behavior Driven Development (BDD)? Short Definition Short Definition “Behaviour‐driven development is about implementing an application by describing its behaviour from the perspective of its stakeholders” – Dan North A Bit More Complete A Bit More Complete "a second‐generation, outside–in, pull‐based, multiple‐ stakeholder, multiple‐scale, high‐automation, agile , p , g , g methodology. It describes a cycle of interactions with well‐ defined outputs, resulting in the delivery of working, tested software that matters. tested software that matters " – Dan North Dan North
- 3. Second Generation Built On … Second Generation Built On … User Stories User Stories eXtreme Programming (XP) eXtreme Programming (XP) – Test Driven Development –AAcceptance Driven Test Planning t Di T t Pl i – Continuous Integration (Automation) Domain‐Driven Design
- 4. Outside‐In Methodology Outside In Methodology Stories describe Stories describe features from the stakeholders POV Development delivers Runnable Tested Runnable Tested Features aka software that matters
- 6. Multiple Stakeholder Multiple‐Stakeholder • Multiple stakeholders (should) define an application’s behavior • Each stakeholder represents one or more business domains – Each domain uses a particular jargon or domain language • Stakeholders involvement for OnPay Story Content – Product: customer interactions, payments knowledge, SLAs – Sales: sales programs (discounts), negotiating SLAs Sales: sales programs (discounts) negotiating SLAs – Accounting: reconciliation, booking revenue, SOX & SAS‐70 compliance – Security: authentication, encryption, web‐attacks, other PCI compliance items – Data Center: app monitoring, patching , system capacity, other ITIL funcs Data Center: app monitoring patching system capacity other ITIL funcs – Legal: user agreements, fee language, SLA agreements – Customer Support: call support performance, support tool effectiveness – Web Design: website appearance (UI Widgets) and usability Web Design: website appearance (UI Widgets) and usability
- 7. User Stories Overview User Stories Overview • Created a planning tool Created a planning tool – Must have a business value – Must be testable Must be testable – Small enough to fit in a sprint / iteration • E h i Emphasizes conversations over specifications ti ifi ti • Narrative describes a feature – One or more stories can describe a feature • Acceptance Criteria defines doneness p
- 8. The Team Writes the Story The Team Writes the Story • SHs describe features & outcomes in the 1st draft SHs describe features & outcomes in the 1 • All work together to complete the story – Express interactions between domain objects as well Express interactions between domain objects as well defined and verifiable behaviors – Blend terms from multiple domains to create a ubiquitous language used by the team to write the story. – Leverage expertise within the team h h • QA identifies testable contexts, Dev estimates the scope, Web Design maps user interaction onto UI elements g p
- 9. BDD Story Format BDD Story Format Title (one line describing the story) Narrative: • Described as a User Story In order to [benefit] • Uses a Ubiquitous Language (UL) developed by the team As a [role] • Benefit is the rationale, might be testable I want to [feature] • Should fit in an sprint, otherwise break up into smaller stories Acceptance Criteria: Scenario: Title • Describes outcomes for an event. Given [context] • The event describes the feature And [some more context]... • Must be testable When [event] • Not always simple Then [outcome] [ ] • gp Minimize domain mixing per scenario And [another outcome]... Scenario: ... • Describes another outcome for another event and context
- 10. P2P Send Money Story P2P Send Money Story Title (one line describing the story) Send P2P Money Narrative: Narrative: In order to [benefit] In order to spend less time paying my debts in person or by mail As a [role] As a Person I want to send money online to another Person I want to send money online to another Person I want to [feature] Scenario: Payor has enough funds Scenario: Title Given Bob is logged into his account page and has an available Given [context] balance of $100 $ And [some more context]... When filling out the send money form with $90.01 in the amount When [event] field, sue@localhost in the recipient field and clicking on the submit Then [outcome] button Then OnPay updates the account page with an available balance of And [another outcome]... [ ] $90 and a pending $10 transaction to sue@localhost $90 and a pending $10 transaction to sue@localhost And adds a payment notification to the account page for Sue in the notifications section Scenario: ... Scenario: Scenario : Payor does not have enough funds y g
- 11. Pull Based is better than Push Based Pull Based is better than Push Based • Pushing is imposed features & deadlines us g s posed eatu es & dead es – What we need is you to develop this by last week • Pulling is more efficient and enables scaling g g – Stories are prioritized by business value. • Clarifies relative importance – The team commits to story delivery based on priority and capacity • Creating sub‐stories when required g q – With a deep backlog more than one team can help – Pulling requires Outside In communication
- 12. The Pull Cycle The Pull Cycle • SHs add BV prioritized stories to the backlog SHs add BV prioritized stories to the backlog. • Dev pulls the highest priority stories to work on that fit in a sprint. on that fit in a sprint • Dev demonstrates completed stories as Runnable Tested Features (RTF) to SHs. R bl T dF (RTF) SH – RTF is software that matters. • The business pulls a collection of RTFs to release as an application or update.
- 14. The Red Green Refactor TDD Cycle The Red‐Green‐Refactor TDD Cycle 1) Write a Test First (fails) jUnit, TestNG 3) Refactor 2) Code Until 2) Code Until Test Passes
- 15. BDD Testing is not Unit Testing BDD Testing is not Unit Testing • jUnit was written for developers jUnit was written for developers – Does a great job for object / unit testing – Popularized “code by example” development p y p p • Cumbersome to adapt for story testing – Test names are method names Test names are method names – Test runners assume one test per object lifetime – jUnit reports use asserts and their stack traces to j p describe failures • It takes a developer to understand what failed.
- 16. The BDD Cycle The BDD Cycle 1) Focus on one ) scenario 2) Write a failing step definition 3) Write failing example 5) Refactor 4) Get example to pass t 7) Refactor 6) Step Up when jbehave, Example Passes Example Passes easyb
- 17. jbehave Overview jbehave Overview • Automates story testing Automates story testing – Parses stories written in text, ODT and Google Docs – Executes stories synchronously or asynchronously Executes stories synchronously or asynchronously – Enables Outside‐In development • Integrates with existing test runners Integrates with existing test runners – jUnit, TestNG, Spring Test – Enables integrate with maven ant eclipse Enables integrate with maven, ant, eclipse • Emits stakeholder readable reports – Supports custom templates Supports custom templates
- 18. Remote Web Testing Client Remote Web Testing Client jbehave Test Runner Test Runner steps stories jUnit / Spring / TestNG embedder story maps selenium Test runner dependent configuration classes firefox
- 19. Direct Testing Application Direct Testing Application jbehave Test Runner Test Runner steps stories jUnit / Spring / TestNG application embedder story maps code Test runner dependent configuration classes
- 20. jbehave Usage jbehave Usage 1. Write a Story 1 Write a Story 2. Configure Embedder and Story Mapper – Li k t i Links stories, steps and reports together t d t t th 3. Implement steps using the BDD Cycle – Annotations associate steps with methods 4. Run the story 5. View Generated Reports
- 21. Mapping Steps with Annotations Mapping Steps with Annotations package com.forceassociates.onpay_webtester.steps; import i org.jbehave.core.annotations.Given; j i i import org.jbehave.core.annotations.Then; import org.jbehave.core.annotations.When; import org.junit.Assert; org junit Assert; public class P2PSendMoneySteps { @Given("$payor is logged into his account page") public void loginToAccountPage(String payor) { // Add code under test or // Selenium client action here to carry out the step } }
- 22. Handling the Unexpected Handling the Unexpected • P2P Send Money Story needs registered users P2P Send Money Story needs registered users – Need additional stories describing registration • How to handle with in an Agile project How to handle with in an Agile project – Review options with your team – Focus on creating a story that matters • Create missing stories & implement to cover gap •M k i i Mock missing services & data i &d t • Last resort is returning the story to the backlog
- 23. Register People Story g p y Narrative: In order to use OnPay As a Person I want to register for OnPay Scenario: Person Registers for OnPay Given a browser is on the OnPay registration page When filling out the registration form with <name> in the name field, <email> in the email address field, <amount> in the initial funding field and clicking on the submit button Then OnPay creates an account for <name> and displays their account page Examples: |name |email |amount | | |Bob|bob@localhost|$100| | @ |$ | |Sue |sue@localhost |$450|
- 24. Dependant Given Story for a Scenario Dependant Given Story for a Scenario P2P Send Money Narrative: In order to spend less time paying my debts in person or by mail As a Person I want to send money online to another Person Scenario: Payor has enough funds GivenStories: com/forceassociates/onpay_webtester/stories/RegisterPeople.given.txt Given Bob is logged into his account page and has an available balance of $100 Bob is logged into his account page and has an available balance of $100 When filling out the send money form with $90.01 in the amount field, sue@localhost in the recipient field and clicking on the submit button Then OnPay updates the account page with an available balance of $90 and a pending $10 transaction to sue@localhost And adds a payment notification to the account page for Sue in the notifications section
- 25. Invoking jbehave Invoking jbehave • Maven Plugin Maven Plugin – jbehave archetypes use integration‐test phase • mvn integration‐test – Very customizable • Eclipse – Execute as a jUnit test or using m2eclipse • Example story report on the next two pages l h
- 29. Other Testing Thoughts Other Testing Thoughts • Story tests are long lived Story tests are long lived – Should be used for regression tests – Subset for used for build acceptance tests – Must be kept up to date • Testing Low Level Code – Interactions bet een objects are beha iors Interactions between objects are behaviors – Can be done with either jBehave or jUnit
- 30. Restart the BDD Cycle Restart the BDD Cycle • Facilitate story development Facilitate story development – Provide a demo instance to SHs – Mock out features not implemented yet Mock out features not implemented yet
- 31. Bibliography • Kent Beck – Extreme Programming Explained (2nd Edition), Addison‐Wesley Professional, 2004 – Test Driven Development: By Example, Addison‐Wesley Professional, 2002 – Web: http://www.threeriversinstitute.org/blog/ • Mike Cohn – Applied Users Stories: For Agile Software Development, Addison‐Wesley‐Professional, 2004 – Web: http://www.mountaingoatsoftware.com/topics/user‐stories • Eric Evans – Domain‐Driven Design: Tackling Complexity in the Heart of Software, Addison‐Wesley Professional, 2003 D i Di D i T kli C l i i h H fS f Addi W l P f i l 2003 – Web: http://domaindrivendesign.org/ • Dan North – The RSpec Book: Behaviour Driven Development with Rspec, Cucumber, and Friends, Pragmatic Bookshelf, 2010 The RSpec Book: Behaviour Driven Development with Rspec Cucumber and Friends Pragmatic Bookshelf 2010 – Web: http://dannorth.net/ http://behaviour‐driven.org/BehaviourDrivenDevelopment http://www.slideshare.net/skillsmatter/bdd‐introduction – jBehave: http://jbehave.org/
- 32. Presenter Information Presenter Information Gordon Force Jr. Gordon Force Jr Principal at Force Associates Email: gordon@force‐associates.com Email gordon@force associates com Twitter: @forceassociates Example source code: https://github.com/gordon force Example source code: https://github com/gordon‐force‐ associates/onpay‐webtester