Introduction to BDD

335 views

Published on

Introduction to BDD

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

  • Be the first to like this

No Downloads
Views
Total views
335
On SlideShare
0
From Embeds
0
Number of Embeds
234
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Good narrative, but cannot be tested
  • Drop the template.  Like everything, once we have a hammer we start looking for nails. Sometimes the template doesn't fit. That's ok. In that case...
    Tell the story in a sentence. Maybe two. When people are presented with a new idea, don't make them read heaps of documents. Sum it up, so they can grasp it quickly. Details can come later. And make sure it's a story, with a beginning, middle and an end. People remember and consume stories better. You can even sing it if you want, that would make it more memorable. Next you want to...
    Anchor it. You know the "It's like Uber, but for...?" pitch form every start up  is using? Everybody knows Uber, so they have something to reference the new information. In story-land it's how the story fits into the application. "It's like the log-in story from last week, but with extra validation". Or, "Once we've done with the simple path, we can add more informed algorithms". You're showing where we were, where we're going, and where this story fits. Then it gets interesting.
    Unveil the motive. Why are we developing this anyway? Who is going to benefit and how? The user may be able to go through registration quicker, and that means more happy users. Or we, the company, gets more money from the dog accessories suppliers, if we're able to connect our users based on their level of pet appreciation. There's a reason we're developing the feature, and it really helps to know the final goal. In some cases, we can debunk it, and choose something better to do with our time. Once people understand the motive...
    Make a show. How does it look like? You have prepared some mock-up screens, or sketches, or drawing of a flow, or anything that has more meat, right? Ah, you need to prepare for this, young Padawan. It will help, not just with explaining it, but it's a also the setting for...
    Give it context.Now that things begin to materialize, it's time for an example. You can present the flow on those mocked screens. Or how a different application might be using our new API. How future features will be using our back-end  calculation results. Context is awesome! We can use it to direct the team towards...
    Generalize. Do we start with the example and just implement it? Should we write a more extensive data validation layer, and then test it? Somewhere in between? An example is not enough for development, because we need to know where to stop. And we need to know how to test. This really helps with defining the acceptance criteria. The final step is...
    Draw a line in the sand. Some things do not fall into our general rule.  VIPs do not need to enter their credentials again. Anonymous users can use the applications, but will go through a separate flow we'll define later. Anything that does not fall within our boundaries, should be presented. Otherwise, we would implement it, and test it, and we will be surprised. And we don't like surprises.
  • Drop the template.  Like everything, once we have a hammer we start looking for nails. Sometimes the template doesn't fit. That's ok. In that case...
    Tell the story in a sentence. Maybe two. When people are presented with a new idea, don't make them read heaps of documents. Sum it up, so they can grasp it quickly. Details can come later. And make sure it's a story, with a beginning, middle and an end. People remember and consume stories better. You can even sing it if you want, that would make it more memorable. Next you want to...
    Anchor it. You know the "It's like Uber, but for...?" pitch form every start up  is using? Everybody knows Uber, so they have something to reference the new information. In story-land it's how the story fits into the application. "It's like the log-in story from last week, but with extra validation". Or, "Once we've done with the simple path, we can add more informed algorithms". You're showing where we were, where we're going, and where this story fits. Then it gets interesting.
    Unveil the motive. Why are we developing this anyway? Who is going to benefit and how? The user may be able to go through registration quicker, and that means more happy users. Or we, the company, gets more money from the dog accessories suppliers, if we're able to connect our users based on their level of pet appreciation. There's a reason we're developing the feature, and it really helps to know the final goal. In some cases, we can debunk it, and choose something better to do with our time. Once people understand the motive...
    Make a show. How does it look like? You have prepared some mock-up screens, or sketches, or drawing of a flow, or anything that has more meat, right? Ah, you need to prepare for this, young Padawan. It will help, not just with explaining it, but it's a also the setting for...
    Give it context.Now that things begin to materialize, it's time for an example. You can present the flow on those mocked screens. Or how a different application might be using our new API. How future features will be using our back-end  calculation results. Context is awesome! We can use it to direct the team towards...
    Generalize. Do we start with the example and just implement it? Should we write a more extensive data validation layer, and then test it? Somewhere in between? An example is not enough for development, because we need to know where to stop. And we need to know how to test. This really helps with defining the acceptance criteria. The final step is...
    Draw a line in the sand. Some things do not fall into our general rule.  VIPs do not need to enter their credentials again. Anonymous users can use the applications, but will go through a separate flow we'll define later. Anything that does not fall within our boundaries, should be presented. Otherwise, we would implement it, and test it, and we will be surprised. And we don't like surprises.
  • Introduction to BDD

    1. 1. @gil_zilberfeld Introduction to BDD
    2. 2. @gil_zilberfeld Hello! I AM GIL ZILBERFELD www.gilzilberfeld.com www.everydayunittesting.com @gil_zilberfeld
    3. 3. @gil_zilberfeld A history lesson…
    4. 4. @gil_zilberfeld eXtreme Programming ◉User stories ◉System metaphor (and DDD’s ubiquitous language) ◉Customer is always available ◉Unit-test first ◉Acceptance tests
    5. 5. @gil_zilberfeld What are the benefits of test-first?
    6. 6. @gil_zilberfeld
    7. 7. @gil_zilberfeld The Three Amigos George Dinwiddie Developer Tester Business analyst
    8. 8. @gil_zilberfeld Behavior driven development Dan North AKA: Acceptance test DD Specification by example Example DD
    9. 9. @gil_zilberfeld It’s all about the conversations!
    10. 10. @gil_zilberfeld
    11. 11. @gil_zilberfeld Where do stories come from?
    12. 12. @gil_zilberfeld Give me an example!
    13. 13. @gil_zilberfeld Ambiguous requirements The Movie
    14. 14. @gil_zilberfeld BDD/ATDD frameworks Fit Fitnesse JBehave Cucumber SpecFlow
    15. 15. @gil_zilberfeld The Gherkin language
    16. 16. @gil_zilberfeld Steps Scenarios Narratives/Features
    17. 17. @gil_zilberfeld Scenario Given I’m driving a Formula 1 car When I start accelerating from 0km/h Then I get to 100km/h in 2 seconds
    18. 18. @gil_zilberfeld The Story (or Narrative) In order to drive faster As a driver I want a better engine
    19. 19. @gil_zilberfeld What is the acceptance criteria?
    20. 20. @gil_zilberfeld How’s this story? In order to approve a transaction As a user I want to press the “Approve” button
    21. 21. @gil_zilberfeld And this one? In order to transfer money As a user I want to login to the app
    22. 22. @gil_zilberfeld BDD/ATDD frameworks Fit Fitnesse Concordion JBehave Cucumber SpecFlow
    23. 23. @gil_zilberfeld Demo
    24. 24. @gil_zilberfeld Good user stories Independent Negotiable Valuable Estimable Small Testable Bill Wake, 2003
    25. 25. @gil_zilberfeld Good user stories Independent Negotiable Valuable Estimable Small Testable
    26. 26. @gil_zilberfeld Ron Jeffries said As an author of the Agile Manifesto I want that stupid story format to go away So that people can get to the essence of user stories
    27. 27. @gil_zilberfeld Better user stories ◉ Drop the template ◉ Tell the story in a sentence ◉ Anchor it ◉ Unveil the motive
    28. 28. @gil_zilberfeld Better user stories ◉ Imagine the demo ◉ Give context ◉ The general rules ◉ Exception to the rules
    29. 29. @gil_zilberfeld Thanks! ANY QUESTIONS? You can find me at: @gil_zilberfeld http://www.GilZilberfeld.com http://www.EverydayUnitTesting.com

    ×