Downloaded 51 times
![Gherkin – Elevating Exercise
Feature: As a condo resident I want to use any of the two available elevators to get
from floor to floor
Scenario: Getting into an elevator from the ground floor
Given [No] Elevators are present on the [ground] floor
And An elevator has not been requested
And Elevator [A] is not moving, currently at floor [2]
And Elevator [B] is going up, currently at floor [5]
When I press the [up] button
Then Elevator [A] gets the call
And Elevator [A] arrives on the [ground] floor and opens doors](https://image.slidesharecdn.com/behaviordrivendevelopmentincontext-141110174503-conversion-gate02/85/Behavior-Driven-Development-BDD-in-context-16-320.jpg)
![From Gherkin to Code
BDD Step: Elevator A gets the call
BDD Framework:
ElevatorAPI.callElevator(ground level, direction up);
BDD Framework:
If(Not ElevatorAPI.callAcknowledged(ground level))
Throw new Exception(“Elevator not called”);
BDD Step: I press the [up] button](https://image.slidesharecdn.com/behaviordrivendevelopmentincontext-141110174503-conversion-gate02/85/Behavior-Driven-Development-BDD-in-context-18-320.jpg)
![Demo
Feature: User status update
Scenario: Normal flow, user is able to login and post a status update
Given I go to "www" with url "/"
And I fill in element "//*[@id='signin-email']" with value "agiledemo"
And I fill in element "//*[@id='signin-password']" with value
"demoagile"
And I click element "//*[@id='front-
container']/div[2]/div[2]/form/table/tbody/tr/td[2]/button"
And I verify current url path is "/"
And I verify text present "AgileDemo"
And I verify text present "@agiledemo"
And I ensure text not present "Writing a BDD presentation"
When I fill in element "//*[@id='tweet-box-mini-home-profile']"
with value "Writing a BDD presentation"
And I click element
"//*[@id='timeline']/div[1]/div/form/div[2]/div[2]/button"
Then I verify text present "Writing a BDD presentation"](https://image.slidesharecdn.com/behaviordrivendevelopmentincontext-141110174503-conversion-gate02/85/Behavior-Driven-Development-BDD-in-context-19-320.jpg)
![Gherkin – Elevating Exercise
Feature: As a condo resident I want to use any of the two available elevators to get
from floor to floor
Scenario: Getting into an elevator from the ground floor
Given [No] Elevators are present on the [ground] floor
And An elevator has not been requested
And Elevator [A] is not moving, currently at floor [2]
And Elevator [B] is going up, currently at floor [5]
When I press the [up] button
Then Elevator [A] gets the call
And Elevator [A] arrives on the [ground] floor and opens doors](https://image.slidesharecdn.com/behaviordrivendevelopmentincontext-141110174503-conversion-gate02/75/Behavior-Driven-Development-BDD-in-context-16-2048.jpg)
![From Gherkin to Code
BDD Step: Elevator A gets the call
BDD Framework:
ElevatorAPI.callElevator(ground level, direction up);
BDD Framework:
If(Not ElevatorAPI.callAcknowledged(ground level))
Throw new Exception(“Elevator not called”);
BDD Step: I press the [up] button](https://image.slidesharecdn.com/behaviordrivendevelopmentincontext-141110174503-conversion-gate02/75/Behavior-Driven-Development-BDD-in-context-18-2048.jpg)
![Demo
Feature: User status update
Scenario: Normal flow, user is able to login and post a status update
Given I go to "www" with url "/"
And I fill in element "//*[@id='signin-email']" with value "agiledemo"
And I fill in element "//*[@id='signin-password']" with value
"demoagile"
And I click element "//*[@id='front-
container']/div[2]/div[2]/form/table/tbody/tr/td[2]/button"
And I verify current url path is "/"
And I verify text present "AgileDemo"
And I verify text present "@agiledemo"
And I ensure text not present "Writing a BDD presentation"
When I fill in element "//*[@id='tweet-box-mini-home-profile']"
with value "Writing a BDD presentation"
And I click element
"//*[@id='timeline']/div[1]/div/form/div[2]/div[2]/button"
Then I verify text present "Writing a BDD presentation"](https://image.slidesharecdn.com/behaviordrivendevelopmentincontext-141110174503-conversion-gate02/75/Behavior-Driven-Development-BDD-in-context-19-2048.jpg)
Uploaded byAlexander Kress
Behavior-Driven Development (BDD) in context
Behavior-driven development (BDD) is presented as an effective addition to agile software processes, promoting improved communication among stakeholders and leading to fewer bugs. It utilizes a common language (Gherkin) to define desired behaviors through user stories and scenarios, facilitating collaboration between product owners, developers, and QA. BDD emphasizes automating testing as part of the development process, ensuring the delivery of working and tested software while enhancing resource utilization within teams.
More Related Content
Similar to Behavior-Driven Development (BDD) in context
Behavior-Driven Development (BDD) in context
- 1. Behavior-Driven Development in Context ALEXANDER KRESS TORONTOAGILE AND SOFTWARE 2014
- 2. About me Development managerat Worked with BDD based process for 5 years Blog devmngr.wordpress.com Twitter @al3xkress
- 3. The sales pitch BDDis a natural addition to an Agile process BDD enhances communication in an agile group BDD leads to fewer bugs and misunderstandings BDD is easy to introduce and understand Lots of open source tools exists to support a BDD roll out
- 4. Mанифест “Аджаил”-манифест разработки программногообеспечения Люди и взаимодействие важнее процессов и инструментов Работающий продукт важнее исчерпывающей документации Сотрудничество с заказчиком важнее согласования условий контракта Готовность к изменениям важнее следования первоначальному плану То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.
- 5. Manifesto Manifesto for AgileSoftware Development Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.
- 6.
- 7. BDD in Context FromUser Stories to BDD
- 8. The user story Asa Twitter user I would like to be able to post status updates In order to alert my followers to my latest doings How would you break this up?
- 9. Let’s add TDD Adda test Run all tests and see if the new one fails Write some code Run the automated tests and see them succeed Refactor code Repeat
- 10. Writing tests ishard To consider: Which parts of the story do we want to test? How do we structure test names to make them readable? Would specific keywords in test names better define what they do? What if we stopped thinking about tests and start thinking about behaviors?
- 11. Behavior-Driven Development BDD isa second-generation, outside–in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well- defined outputs, resulting in the delivery of working, tested software that matters. Dan North Also see http://dannorth.net/introducing-bdd/
- 12. BDD in Context Nutsand Bolts
- 13. Gherkin – thelanguage Feature: Some terse yet descriptive text of what is desired In order to realize a named business value. Scenario: Some determinable business situation Given some precondition And some other precondition When some action by the actor And some other action And yet another action Then some testable outcome is achieved And something else we can check happens too Behat documentation Step Body
- 14. Gherkin – ElevatingExercise Feature: As a condo resident I want to use any of the two available elevators to get from floor to floor Scenario: Getting into an elevator from the ground floor Given And When And And Then And
- 15. Gherkin – ElevatingExercise Feature: As a condo resident I want to use any of the two available elevators to get from floor to floor Scenario: Getting into an elevator from the ground floor Given No Elevator is present on the ground floor And An elevator has not been requested And Elevator A is not moving, currently at floor 2 And Elevator B is going up, currently at floor 5 When I press the up button Then Elevator A gets the call And Elevator A arrives on the ground floor and opens doors
- 16. Gherkin – ElevatingExercise Feature: As a condo resident I want to use any of the two available elevators to get from floor to floor Scenario: Getting into an elevator from the ground floor Given [No] Elevators are present on the [ground] floor And An elevator has not been requested And Elevator [A] is not moving, currently at floor [2] And Elevator [B] is going up, currently at floor [5] When I press the [up] button Then Elevator [A] gets the call And Elevator [A] arrives on the [ground] floor and opens doors
- 17. From Gherkin toCode Java Ruby Python Lettuce ---> PHP JavaScript and many others API
- 18. From Gherkin toCode BDD Step: Elevator A gets the call BDD Framework: ElevatorAPI.callElevator(ground level, direction up); BDD Framework: If(Not ElevatorAPI.callAcknowledged(ground level)) Throw new Exception(“Elevator not called”); BDD Step: I press the [up] button
- 19. Demo Feature: User statusupdate Scenario: Normal flow, user is able to login and post a status update Given I go to "www" with url "/" And I fill in element "//*[@id='signin-email']" with value "agiledemo" And I fill in element "//*[@id='signin-password']" with value "demoagile" And I click element "//*[@id='front- container']/div[2]/div[2]/form/table/tbody/tr/td[2]/button" And I verify current url path is "/" And I verify text present "AgileDemo" And I verify text present "@agiledemo" And I ensure text not present "Writing a BDD presentation" When I fill in element "//*[@id='tweet-box-mini-home-profile']" with value "Writing a BDD presentation" And I click element "//*[@id='timeline']/div[1]/div/form/div[2]/div[2]/button" Then I verify text present "Writing a BDD presentation"
- 20. BDD in Context Tyinginto Agile
- 21.
- 22. Common language PO DevQA BDD as acceptance criteria BDD as requirements definition and Test First Then Code methodology BDD as functionality definition and automated regression
- 23. Working together Anyone canwrite a BDD!
- 24. Working together We defineour own language!
- 25. Working together Optimizing resourceutilization PO DEV QAScenarios and steps
- 26. Adding BDD toyour process Work with POs to understand and learn to love BDDs Work with developers to read and write BDDs QA will be your biggest fan
- 27. Working with BDD Mindthe testing pyramid (Mike Cohn) Write BDDs in the same sprint Refactor, Refactor, Refactor BDD -> CI -> Regression report UI Service Unit
- 28.
- 29. FAQ How to createcoverage for an existing system? Which BDD framework language to pick? Why not use QTP or some version of clicks recorder/capture? Do POs really need to speak “fluent” Gherkin?
- 30. Behavior-Driven Development BDD isa second-generation, outside–in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well- defined outputs, resulting in the delivery of working, tested software that matters. Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
- 31.
- 32. RedFlagDeals Case Study Q12012 – Large code base, no unit test, manual QA only Q2 2012 – BDD framework introduced, QA start to dabble in it Q3 2012 – First new component to have 100% BDD code coverage Q1 2013 – BDD roll out across the team, PO training Q2 2013 – Over 60% coverage on legacy components Today – 587 scenarios, 10,353 steps (executed) Full nightly regression Commit triggered BDD execution Agreed on failure review and correction process Automation being part of the Definition of Done
- 33. More Gherkin features Tags @DailyRegression Feature:rss @STORY-5859 @Staging @Local Scenario: check vital signs Given I go to … Tables And call the url “www.site.com” with parameters | Parameter Name | Parameter Value | | search_string | agile | | page_number | 5 |
- 34. Refactoring steps When Iclick on the Submit button When I click on the Clear button When I click on the “Publish” button When I hover over the “Help” button When I “hover over” the “Help” button When I “hover over” the “Avatar” image When I “hover over” the control “image” called “Avatar”
- 35. Using Mocks BDD drivenautomation behaves like a user, easy to start clicking on “real” or staging apps/sites/etc. Somewhere, someone had just put up a prod database snapshot
- 36. Closing pitch Common language! Codebased documentation that is readable by all. Better resource utilization in the team. A natural extension to an Agile process.
Editor's Notes
- #5 Can you read this? Wait until people indicate no, before going to the next slide.
- #6 The previous slide is now clear. Although not to this extreme but this is not too far what happen when POs, Devs and QA communicate
- #7 Three different ways of looking at the same thing. Even with Agile user stories what PO sees does not nearly match what Dev or QA look at. We do not have a common language.
- #9 The simple truth that a user story can "hide" numerous scenarios under it
- #10 Brief discussion of what is TDD. Mention that TDD is the basis for BDD
- #12 Dan North came up with the concept of BDD when he realized that what he was trying to do with his tests was more than TDD. Read over the definition, mention that we will come back to the highlighted parts. Outside-in: A strategy for integration testing where units handling program inputs and outputs are tested first, and units that process the inputs to produce output are incrementally included as the system is integrated. A form of hybrid testing. "pull-based" - outside-in, plus Feature Injection to make it pull at the analysis level. BDD is about writing software that matters - we tend not to produce software that isn't already about to be used, either by people or by code closer to the UI. "multiple-stakeholder" - Stakeholders aren't the same as users. This is also from Feature Injection. "multiple-scale" - All the way up from code to release, also works on everything from tiny toy projects to huge great Enterprise efforts. Not sure which of these Dan was referring to here. "high-automation" - Because not having the scenarios and examples automated rapidly becomes expensive.
- #14 The basic parts of BDD. Mention Feature and Scenario. Ask what Given When Then looks like (user story) compare to “As someone I do so That”
- #15 Ask the audience to supply missing steps
- #16 One alternative to complete the exercise
- #17 Same but with steps parameters
- #18 Once your Gherkin definitions are setup there is a framework for almost any language you are familiar with. The framework allows to translates individual steps into code that drives your application. BDDs can be used to test any application, in particular Web, APIs or Mobile apps
- #22 Three different ways of looking at the same thing. Even with Agile user stories what PO sees does not nearly match what Dev or QA look at. We do not have a common language.
- #23 Three different ways of looking at the same thing. Even with Agile user stories what PO sees does not nearly match what Dev or QA look at. We do not have a common language.
- #24 We are no longer limited to generation output limited to out domain of expertise. Anyone on the SCRUM team can create a BDD and it will be understood by others on the team. Further, everyone is expected to be writing BDDs are they are working on their part of the Agile story.
- #25 BDD is a language, steps are getting reused. People do not only use the same framework to communicate, but they build a language as they develop features.
- #27 POs have trouble going to BDD, understanding that BDDs are just a way to express acceptance criteria helps Developers have no problems reading BDDs, the hard part is to convince them to participate in BDD creation process. Not all teams are TDD already, and even if your team is, BDDs are still a change from normal. QA needs to be on board, but this process ends up making their live so much easier that no convincing is usually required
- #30 Unit tests have their place, but unit tests are not functional tests. Teams can get away with just functional testing (BDDs), but there it nothing wrong with having both BDD and TDD Tests will accumulate and will need to be maintained. Not every PO requirement expressed in BDD needs to be coded up, there is a balance that will be determined based on each specific product No way around it, it will be long and may be painful. However it can be done, I’ve done this twice, most recently we have achieved a 90% coverage in a year and a half on a very large code base. If your system is smaller or changing rapidly it will go faster. Rules about when to set up tests – on new components only, on touching old components, 5% of the sprint time goes towards BDD on legacy code, will help.
- #31 I want to conclude by looking at the Agile manifesto and Dan North’s definition together. Why is BDD an inherent addition to the Agile process? One of the reasons is how well it fits with the original definition of agile. It improves interaction, it results in documenting the code in code. In essence BDD is a tool to improve collaboration within your team, to create cleaner and less error prone software.