Downloaded 12 times
Uploaded byShawn Wallace
Introduction to atdd
The document introduces Behavior Driven Design (BDD) as an approach to enhance agile development practices by focusing on the user perspective and efficient communication. It emphasizes the importance of vertical slicing for delivering functionality quickly and outlines the benefits and components of BDD, including executable requirements and acceptance tests. Various tools and resources for implementing BDD, such as Cucumber and community support, are also discussed.
More Related Content
Similar to Introduction to atdd
Introduction to atdd
- 1. An Introduction to Behavior Driven Design Shawn Wallace National Service Offering Lead Application Development and Application Lifecycle Management Senior Architect Centric Consulting
- 2.
- 3.
- 4.
- 5. I’m Shawn Favorite Movie Mydog My Son
- 6. I’m Shawn Favorite Movie Mydog My Son My Daughter
- 7. I’m Shawn Favorite Movie Mydog My Son My Daughter My Family
- 8. I’m Shawn Favorite Movie Mydog My Son My Daughter My Family I live here
- 9. I’m Shawn Favorite Movie Mydog My Son My Daughter My Family I live here I a Marine Vet
- 10. I’m Shawn Favorite Movie Mydog My Son My Daughter My Family I live here I a Marine Vet My Favorite Team
- 11. I’m Shawn Favorite Movie Mydog My Son My Daughter My Family I live here I a Marine Vet My Favorite Team Where I work
- 12.
- 13. A programmer isgoing out for a stroll one evening. His wife asks him to swing by the store and pick up a gallon of milk, and if they had eggs, to get a dozen. He returned with twelve gallons of milk and said "They had eggs." 4
- 14.
- 15. Our existences are about precise communication
- 16. The Problem withAgility
- 18. We are tryingto “productize” our approaches...again.
- 19. We are tryingto “productize” our approaches...again.
- 20. Fundamentally agile is about approachingthe work in a different way. 11
- 21.
- 22. We need thinking businessanalysts
- 23.
- 24.
- 25. We’re not buildinga house...
- 26. We’re cleaning the house...
- 27. It’s NOT easy • It is MUCH easier to slice up a backlog horizontally • Developers want to work horizontally (efficiency argument) http://simpleprogrammer.com/2011/11/21/understanding-the-vertical-slice/
- 28.
- 29. Why vertical slices? Itis about delivering working functionality as soon as possible. Feedback.
- 30.
- 31.
- 32. Why Behavior DrivenDesign • Work is done from the perspective of the user • Can slice vertically but narrowly • Tests behavior of the system • Executable requirements • Need to move as fast as business • Appropriate feedback loop • Manual regression is EXPENSIVE
- 33. Acceptance Tests vs.Unit and Integration Tests
- 34. Acceptance Tests vs.Unit and Integration Tests • Unit Tests confirm that you built it right (INSIDE OUT) • Acceptance Tests confirm that you build the right thing (OUTSIDE IN) 25
- 35. Benefits • Implementing changes more efficiently • Quick feedback • Higher product quality • Less rework • Better work alignment to priority (not just for agile teams) 26
- 36. • Describes howsoftware should behave in plain text • Gherkin – Usable in many different human languages – Features can be written and understood by both non/ technical project members • Not a replacement for unit testing; it’s not a low level testing/spec framework • Easy to execute in Continuous Integration environment (except MS TFS)
- 37. Technology Stack • Cucumber- Domain Specification • Ruby, JRuby or .NET - map cukes to application • UI testing framework - Watir, Watin, Selenium, Capybara (headless), anything that supports WebDriver • Open source • STRONG community support 28
- 38.
- 39. Who’s Using theSystem Features
- 40. Who’s Using theSystem What are they doing? Features
- 41. Who’s Using theSystem What are they doing? Why do they care? Features
- 42. Scenarios • Features aredefined by one or more scenarios • Sequence of steps thru the feature that exercises on path • Use BDD style – given-when-then Scenario: <description> <step 1> …
- 43.
- 44. • Given -Sets up preconditions, or context, for the scenario Scenarios
- 45. • Given -Sets up preconditions, or context, for the scenario • When - The action, or behavior, that we’re focused on Scenarios
- 46. • Given -Sets up preconditions, or context, for the scenario • When - The action, or behavior, that we’re focused on • Then - Checks post-conditions and verifies that the right thing happened in the When stage Scenarios
- 47.
- 48. Q&A For more information... • This Presentation on GitHub - https://github.com/shawnewallace/intro-to-atdd.git • cukes.info • Gojko Adzic – cuke4ninja.com – Specification by Example • https://github.com/aslakhellesoy/cucumber/wiki • http://groups.google.com/group/cukes • http://www.cheezyworld.com • The Cucumber Book, Matt Wayne, Aslak Hellesøy: http://pragprog.com/book/ hwcuc/the-cucumber-book • The Rspec Book, David Chelimsky: http://www.pragprog.com/titles/achbd/the- rspec-book • http://simpleprogrammer.com/2011/11/21/understanding-the-vertical- slice/ • http://www.deltamatrix.com/2012-04-17-04-37-50/horizontal-and- vertical-user-stories-slicing-the-cake
- 49. Shawn Wallace Work: shawn.wallace@centricconsulting.com Personal: shawn@the-wallaces.net Twitter: @ShawnWallace Blog: blog.shawnewallace.com http://www.about.me/shawnwallace Shirt size: XXL Shoe Size: 11.5
Editor's Notes
- #2 There is a lot here for...\n\ndevs, qa, ba and project leadership\n\nMeant to wet your whistle.\n
- #3 A few things about me.\n
- #4 A few things about me.\n
- #5 A few things about me.\n
- #6 A few things about me.\n
- #7 A few things about me.\n
- #8 A few things about me.\n
- #9 A few things about me.\n
- #10 A few things about me.\n
- #11 A few things about me.\n
- #12 A few things about me.\n
- #13 A few things about me.\n
- #14 A few things about me.\n
- #15 A few things about me.\n
- #16 A few things about me.\n
- #17 A few things about me.\n
- #18 A few things about me.\n
- #19 A few things about me.\n
- #20 A few things about me.\n
- #21 A few things about me.\n
- #22 I &#x2018;fear the light&#x2019;\n\nWhy do I care about this?\n
- #23 \n
- #24 our existences are about precise communication\n
- #25 \n
- #26 How many agilists in the room\n
- #27 Nothing about standups, iterations, product owners, \n\nPeople analyze agile by checking how many of these practices you have put in place.\n\nAlready, we have lost our way.\n
- #28 The ceremony has become our goal\n
- #29 The ceremony has become our goal\n
- #30 Not about process, not about ceremony, about delivering working software\n
- #31 \n
- #32 \n
- #33 \n
- #34 \n
- #35 \n
- #36 \n
- #37 \n
- #38 Consider the ATM problem\n
- #39 Thinking about how to break apart a backlog into vertical slices requires us to step outside the understanding of the code and implementation and instead think about the backlog in small pieces of working functionality.\n
- #40 \n
- #41 \n
- #42 \n
- #43 IT needs to be able to move faster than the business must make decisions\n Tests from the perspective of the user\n Tests behavior of the system\n Executable requirements, codefied\n not disposable artifacts\n
- #44 TESTING IS PART OF REQUIREMENTS GATHERING\n TDD is a development practice\n These are fairly accurate ratios\n
- #45 \n
- #46 \n
- #47 \n
- #48 \n
- #49 Within the definition of a feature you can provide a plain text description of the story, focusing on three important questions:\n
- #50 \n
- #51 \n
- #52 \n
- #53 \n
- #54 \n
- #55 \n
- #56 \n
- #57 And can be used in any of the three sections\n It serves as nice shorthand for repeating the Given, When, or Then\n And stands in for whatever the most recent explicitly named step was\n
- #58 \nRuby and .NET\n
- #59 \nRuby and .NET\n
- #60 \nRuby and .NET\n
- #61 \nRuby and .NET\n
- #62 \nRuby and .NET\n
- #63 \nRuby and .NET\n
- #64 \nRuby and .NET\n
- #65 \nRuby and .NET\n
- #66 1) show feature code\n2) show features run\nRED IS BAD\nYELLOW IS NOT IMPLEMENTED\nGREEN IS GOOD\n3) show feature output\n
- #67 \n
- #68 \n
- #69 \n