Your SlideShare is downloading. ×
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Why BDD is our BFF
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Why BDD is our BFF

392

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
392
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Matt Daubert MeYou Health @mdaubs83
  • 2. TDD is about code design
  • 3. “It’s harder to read code than to write it.” - Joel Spolsky
  • 4. “Agile processes harness change” - 2nd Principle, Agile Manifesto
  • 5. “No matter how slow you are writing clean code, you will always be slower if you make a mess.” - Uncle Bob Martin
  • 6. TDD does not address...
  • 7. Which test do I need to write next? Starting point.
  • 8. How do I know when I’ve written the last test? Definition of done.
  • 9. How does this new code add value for the user? Am I writing the right code?
  • 10. Scenario BDD Unit test TDD Refactor Code to pass test
  • 11. “If you can’t explain it simply, you don’t understand it well enough.” - Albert Einstein
  • 12. Developing acceptance tests Implementing acceptance tests
  • 13. Successful products provide value to users. Users derive value by interacting with products. Interactions are testable.
  • 14. Two sides to every (user) story Narrative Acceptance Criteria - User/persona/role - Multiple concrete examples describing how the feature works - Goal or value the user would like to achieve - The interaction the user should have with the product in order to achieve their goal and gain value
  • 15. Our goals, user goals Specification Acceptance Test Living Documentation increasing Domain Language Key Examples Shared Understanding Scope
  • 16. Ain't Nobody Got Time For That
  • 17. Refining User Stories - Stories are refined through collaboration - Stories may divide if they get complex - Stories will often start with a small number of key examples and expand as shared understanding develops - Refinement is complete when a story passes the "INVEST" test.
  • 18. INVEST in User Stories
  • 19. INVEST in User Stories Independent Can be scheduled and re-prioritized with minimal risk of being blocked.
  • 20. INVEST in User Stories Independent Negotiable Can be changed or discarded if business, market, or technical needs require.
  • 21. INVEST in User Stories Independent Negotiable Valuable Stories that don't add value for users will never see a return on investment.
  • 22. INVEST in User Stories Independent Negotiable Valuable Estimable A reasonable idea of effort required to complete is needed to pace the sprint.
  • 23. INVEST in User Stories Independent Negotiable Valuable Estimable Small Quicker to implement, minimize risk, get feedback sooner.
  • 24. INVEST in User Stories Independent Negotiable Valuable Estimable Small Testable A story isn't considered done until its acceptance tests pass.
  • 25. What is an acceptance test? ● Executable version of a refined user story ● Written in domain language ● Scenarios validate story acceptance criteria ● Defines start and finish lines ● Documents value proposition ● Respects "Three Levels of Description"
  • 26. Three Levels of Description Business Rule What is the scenario demonstrating? Scenario: Free delivery is offered to customers who order two or more books
  • 27. Three Levels of Description Business Rule What is the scenario demonstrating? User Workflow How can a user exercise the functionality? Given I put two books in my cart When I checkout Then I should be able to select free delivery
  • 28. Three Levels of Description Business Rule What is the scenario demonstrating? User Workflow How can a user exercise the functionality? Technical Activity What are the technical steps required to exercise each workflow step? step 'I checkout' do click_on 'Checkout' end
  • 29. Protips (Lightning Round)
  • 30. Disambiguate w/Concrete Examples Scenario Outline: Users cannot sign in after the sixth failed sign in attempt over a one day period Given I have failed to sign in <yesterday> times yesterday And I have failed to sign in <today> times today Then I should be <result> to sign in Examples: | yesterday | today | result | | 0 | 0 | able | | 0 | 5 | able | | 0 | 6 | unable | | 5 | 0 | able | | 5 | 5 | able | | 5 | 6 | unable | | 6 | 0 | able | | 6 | 5 | able | | 6 | 6 | unable |
  • 31. Gherkin Protip: Hide Implementation Scenario: Selected customers are notified of a flash sale Given I am a store manager When I create a flash sale for VIP customers that starts tomorrow And it’s tomorrow And Resque jobs are run Then VIP customers receive a Flashmail
  • 32. Gherkin Protip: Hide Implementation Scenario: Selected customers are notified of a flash sale Given I am a store manager When I create a flash sale for VIP customers Then VIP customers receive a Flashmail the day of the flash
  • 33. Gherkin Protip: Don’t Write Scripts As a party planner with BFFs In order to have the best party ever I want to invite as many BFFs as possible Given there is a user named Alice And there is a user named Bob who is BFFs with Alice And there is a user named Charlie who is BFFs with Bob When Alice invites Bob to a party But Alice does not invite Charlie to the same party Then Alice receives a message "Do you also want to invite Charlie?"
  • 34. Gherkin Protip: Don’t Write Scripts As a party planner with BFFs In order to have the best party ever I want to invite as many BFFs as possible Given I am planning a party When I invite my BFF Bob Then I am asked if I might want to invite his BFF Charlie
  • 35. Gherkin Protip: Be skeptical of "I should see" steps Is the act of seeing the thing valuable to the user or is it an implementation detail? Yes Then I should see that the patron has overdue books No Then I should see the overdue book icon
  • 36. Gherkin Protips: Be skeptical of "And" and “But” keywords Are these steps really one step? Are these steps not focused on the feature? Is this feature really two features? Be skeptical of "and" and "or" in steps Is this step really two steps? Is this scenario really two scenarios?
  • 37. Gherkin Protips: Don't test every case Add examples to disambiguate around edge cases Never use generic steps to DRY tests DRY Ruby code behind the steps Listen when your Gherkin fights you Can you explain the feature in simple terms?
  • 38. Use ctags - Never Grep for Steps ● Open a .feature file ● Move cursor to a scenario step ● Press Ctrl+] to open the step definition ● Press Ctrl+t to go back to the .feature file
  • 39. Step Definitions # Gherkin When I sign up with "email@example.com" and "password" # Cucumber step definition When /^I sign up (?:with|as) "(.*)" and "(.*)"$/ do |email, pw| # More Ruby code here end # Turnip step definition step "I sign up with/as :email and :password" do |email, pw| # More Ruby code here end
  • 40. Use Custom Placeholders step "there are :count monsters" do |count| count.times { Monster.new(name) } end placeholder :count do match /d+/, &:to_i # { |count| count.to_i } match /no/ { 0 } end (or use Step Argument Transforms in Cucumber)
  • 41. Use Helper Methods module MyAccountSteps step 'I am modifying my AwesomeApp account' do sign_in @user = create(:user) select_from_user_drop_down 'My account' end end
  • 42. Organize Your Suite spec |- acceptance |- features |- encouragement.feature |- macros |- session_macros.rb |- steps |- encouragement_steps.rb
  • 43. Every product and team is different, optimize for yours.
  • 44. Thanks! Matt Daubert MeYou Health @mdaubs83
  • 45. Learn from smart people http://alindeman.github.io/acceptance_testing http://blog.carbonfive.com/2012/02/14/beginning-outside-in-rails-developmentwith-cucumber-and-rspec/ http://en.wikipedia.org/wiki/INVEST_(mnemonic) http://specificationbyexample.com/ http://janetgregory.blogspot.com/2010/08/atdd-vs-bdd-vs-specification-byexample.html http://www.drdobbs.com/tdd-is-about-design-not-testing/229218691

×