Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Behavior Driven Development


Published on

Published in: Technology

Behavior Driven Development

  1. 1. Introduction to Behavior Driven Development for Java Developers Gordon Force January 10, 2012 January 10, 2012
  2. 2. What is Behavior Driven Development (BDD)? What is Behavior Driven Development (BDD)?Short DefinitionShort Definition “Behaviour‐driven development is about implementing an  application by describing its behaviour from the  perspective of its stakeholders” – Dan NorthA Bit More CompleteA 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. 3. Second Generation Built On … Second Generation Built On …User Stories User StorieseXtreme 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. 4. Outside‐In MethodologyOutside In Methodology Stories describe  Stories describe features from the  stakeholders POV Development  delivers  Runnable Tested  Runnable Tested Features aka  software that  matters
  5. 5. BDD StoriesBDD Stories
  6. 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. 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. 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. 9. BDD Story Format BDD Story FormatTitle (one line describing the story)Narrative: • Described as a User StoryIn order to [benefit] • Uses a Ubiquitous Language (UL) developed by the teamAs a [role] • Benefit is the rationale, might be testableI want to [feature] • Should fit in an sprint, otherwise break up into smaller storiesAcceptance Criteria:Scenario: Title • Describes outcomes for an event.Given [context] • The event describes the feature And [some more context]... • Must be testableWhen [event] • Not always simpleThen [outcome] [ ] • gp Minimize domain mixing per scenario And [another outcome]...Scenario: ... • Describes another outcome for another event and context
  10. 10. P2P Send Money Story P2P Send Money StoryTitle (one line describing the story) Send P2P MoneyNarrative: Narrative:In order to [benefit] In order to spend less time paying my debts in person or by mailAs a [role] As a Person I want to send money online to another Person I want to send money online to another PersonI want to [feature] Scenario: Payor has enough fundsScenario: 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 sectionScenario: ...Scenario: Scenario : Payor does not have enough funds y g
  11. 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. 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.
  13. 13. High Automation: BDD TestingHigh Automation: BDD Testing
  14. 14. The Red Green Refactor TDD CycleThe Red‐Green‐Refactor TDD Cycle 1) Write a Test  First (fails) jUnit, TestNG 3) Refactor 2) Code Until  2) Code Until Test Passes
  15. 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. 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 t7) Refactor 6) Step Up when  jbehave,  Example Passes Example Passes easyb
  17. 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. 18. Remote Web Testing Client Remote Web Testing Client jbehave Test Runner Test Runner steps stories jUnit / Spring / TestNGembedder story maps selenium Test runner dependent configuration classes firefox
  19. 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. 20. jbehave Usage jbehave Usage1. Write  a Story1 Write a Story2. Configure Embedder and Story Mapper – Li k t i Links stories, steps and reports together t d t t th3. Implement steps using the BDD Cycle – Annotations associate steps with methods4. Run the story5. View Generated Reports
  21. 21. Mapping Steps with Annotations Mapping Steps with Annotationspackage com.forceassociates.onpay_webtester.steps;importi org.jbehave.core.annotations.Given; j i iimport 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. 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. 23. Register People Story g p yNarrative:In order to use OnPayAs a PersonI want to register for OnPayScenario: Person Registers for OnPay Given a browser is on the OnPay registration pageWhen 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 pageExamples:|name |email |amount | ||Bob|bob@localhost|$100| | @ |$ ||Sue |sue@localhost |$450|
  24. 24. Dependant Given Story for a Scenario Dependant Given Story for a ScenarioP2P Send MoneyNarrative:In order to spend less time paying my debts in person or by mailAs a PersonI want to send money online to another PersonScenario: Payor has enough fundsGivenStories: com/forceassociates/onpay_webtester/stories/RegisterPeople.given.txtGiven 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 $100When 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@localhostAnd adds a payment notification to the account page for Sue in the notifications section
  25. 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
  26. 26. 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
  27. 27. 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
  28. 28. Bibliography• Kent Beck – Extreme Programming Explained (2nd Edition), Addison‐Wesley Professional, 2004 – Test Driven Development: By Example, Addison‐Wesley Professional, 2002 – Web:• Mike Cohn – Applied Users Stories: For Agile Software Development, Addison‐Wesley‐Professional, 2004 – Web:‐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:• 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://behaviour‐‐introduction – jBehave:
  29. 29. Presenter Information Presenter InformationGordon Force Jr.Gordon Force JrPrincipal at Force AssociatesEmail: gordon@force‐associates.comEmail gordon@force associates comTwitter: @forceassociatesExample source code: forceExample source code: https://github com/gordon‐force‐ associates/onpay‐webtester