BDD in Action - Devoxx 2014
8 likes2,385 views
The document discusses Behavior-Driven Development (BDD), emphasizing its role in enhancing collaboration between business owners, analysts, developers, and testers to improve software quality and alignment with business needs. It outlines key benefits of BDD, such as reduced maintenance costs and faster releases, while also addressing challenges in adopting BDD practices. The document highlights the importance of clear communication, structured scenarios, and effective tools to facilitate the BDD process.
BDD in Action - Devoxx 2014
- 1. BDD in Action John Ferguson Smart Wakaleo Consulting #DV14 #bddinaction @wakaleo
- 2. Miyamoto Musashi Japan 1584 – 1645 #DV14 #bddinaction @wakaleo
- 3. Consultant Tr a i n e r Mentor Author Speaker Coder John Fer guson Smar t #DV14 #bddinaction @wakaleo
- 4. What is BDD A typical BDD workflow What tools should I use? Effec@ve BDD automa@on BDD Gotchas #DV14 #bddinaction @wakaleo
- 5. So what is this BDD thing? A Test Automa@on Tool? #DV14 #bddinaction @wakaleo
- 6. So what is this BDD thing? A way to write acceptance criteria? #DV14 #bddinaction @wakaleo
- 7. So what is this BDD thing? A way to discover requirements? #DV14 #bddinaction @wakaleo
- 8. So what is this BDD thing? Using examples a shared understanding software that matters #DV14 #bddinaction @wakaleo
- 9. Building the right software Hunting out value Automated Acceptance BDD Criteria API and code design Collaboration Living Documentation Building the software right #DV14 #bddinaction @wakaleo
- 10. The business owner tells the business analyst what he wants 1 BDD in a nutshell 2 The business analyst writes a requirements document 3 The developer translates the requirements into software 4 The tester translates the requirements into test cases 5 The technical writer translates the software into functional and technical documentation A traditional development process #DV14 #bddinaction @wakaleo
- 11. 2 The business owner and the business analyst have a conversation about what he needs. 1 BDD in a nutshell The scenarios guide the developer and act as automated tests 3 The business analyst, the developer and the tester elaborate the requirements together. They define requirements as structured, English-language 4 The tester uses these scenarios as the basis for her tests 5 "scenarios" The automated tests provide feedback on progress and help document the application format A BDD development process #DV14 #bddinaction @wakaleo
- 12. 2 The business owner and the business analyst have a conversation about what he needs. 1 The scenarios guide the developer and act as automated tests 3 The business analyst, the developer and the tester elaborate the requirements together. They define requirements as structured, English-language 4 The tester uses these scenarios as the basis for •Specifica@ons are elaborated collabora@vely •Specifica@ons use her a tests common language •Executable specifica@ons provide fast feedback 5 "scenarios" The automated tests provide feedback on progress and help document the application format #DV14 #bddinaction @wakaleo
- 14. Why bother with BDD? •Focus effort •Reduce waste and misaligned requirements #DV14 #bddinaction @wakaleo
- 15. Why bother with BDD? Deliver more valuable soMware #DV14 #bddinaction @wakaleo
- 16. Why bother with BDD? Make changes safely #DV14 #bddinaction @wakaleo
- 17. Why bother with BDD? Faster and more reliable releases #DV14 #bddinaction @wakaleo
- 18. Why bother with BDD? Reduced maintenance costs #DV14 #bddinaction @wakaleo
- 19. Benefits of BDD BDD BDD in the real world -‐ an example #DV14 #bddinaction @wakaleo
- 20. Adoption challenges Demo BDD requires high business engagement and collabora@on #DV14 #bddinaction @wakaleo
- 21. Adoption challenges Demo BDD works best in an Agile or Itera@ve context #DV14 #bddinaction @wakaleo
- 22. Adoption challenges Demo BDD does not work well in a silo #DV14 #bddinaction @wakaleo
- 23. Adoption challenges Demo Skill and prac@ce required: •Wri@ng good scenarios takes prac@ce •Poorly wriQen tests can lead to higher test-‐maintenance costs •Need to treat test automa@on code like produc@on code #DV14 #bddinaction @wakaleo
- 24. BDD Gotchas 1 2 3 An@-‐paQern 1 The business analyst writes the scenarios 4 and then gives them to the other team members. #DV14 #bddinaction @wakaleo
- 25. 1 2 3 BDD Gotchas An@-‐paQern 2 4 The tester writes the scenarios at the end to implement an automated test suite. #DV14 #bddinaction @wakaleo
- 26. 1 2 3 BDD Gotchas An@-‐paQern 3 4 The “Three Amigos” sessions don’t result in usable scenarios, so the developer invents them a=erwards. 5 #DV14 #bddinaction @wakaleo
- 27. 1 2 3 BDD Gotchas An@-‐paQern 4 4 The scenarios are too UI-‐centric or detail-‐focused, and neglect to express the core business value. 5 #DV14 #bddinaction @wakaleo
- 28. BDD for high-level requirements #DV14 #bddinaction @wakaleo
- 31. Frequent Flyer Application Goal: Encourage travellers to fly with Flying High airlines more often by allowing them to cumulate Frequent Flyer points that they can spend on cheaper flights. Goals Earning points from flights Capabili9es Earning points from spending with partners Viewing points earned Spending points on bookings Viewing current points balance Features View points needed to achieve the next status level Calculating points needed for a given destination #DV14 #bddinaction @wakaleo
- 32. Calculating points needed for a given destination As a traveller I want to know how many points I need to go to a given destination So that I can plan my next trip with Flying High Airlines Feature Acceptance Criteria -Need 2 points per km -Members can calculate points needed on their account home page Acceptance Criteria Automated Acceptance Criteria #DV14 #bddinaction @wakaleo
- 33. Automated Acceptance Criteria Automated Acceptance Tests #DV14 #bddinaction @wakaleo
- 34. Automated Acceptance Tests Applica9on Code Low level specifica9ons #DV14 #bddinaction @wakaleo
- 35. A typical BDD workflow “But what are the deliverables? Meaningful feedback on what requirements have (and have not) been delivered #DV14 #bddinaction @wakaleo
- 36. An incremental approach “But what are the deliverables? Descrip9on of each feature with an example of how it behaves #DV14 #bddinaction @wakaleo
- 37. An incremental approach “But what are the deliverables? …complete with illustra9ons #DV14 #bddinaction @wakaleo
- 38. An incremental approach “But what are the deliverables? How was each feature tested? #DV14 #bddinaction @wakaleo
- 39. An incremental approach “But what are the deliverables? Documenta9on about what you plan to deliver in each release #DV14 #bddinaction @wakaleo
- 40. An incremental approach “But what are the deliverables? Useful low-‐level technical documenta9on with liRle overhead #DV14 #bddinaction @wakaleo
- 41. An incremental approach “But what are the deliverables? …and targeted automated regression tests #DV14 #bddinaction @wakaleo
- 42. Flying High Application Architecture AngularJS SPA Flights Web Service Accounts Web Service Routes Web Service #DV14 #bddinaction @wakaleo
- 43. Flying High Test Architecture (aka Thucydides) #DV14 #bddinaction @wakaleo
- 44. Demo #DV14 #bddinaction @wakaleo
- 45. BDD for detailed coding #DV14 #bddinaction @wakaleo
- 46. Business Goal Business Goal Business Goal “building the software right” FFeFeaeatatuturureresess FFeEeaxatatumurrepesless Low level speLcoifiwc aletvioenl s speLcoifiwc alteivoenls specifications Executable specifications We can automate these examples in the form of “executable specifica@ons” #DV14 #bddinaction @wakaleo
- 47. Business Goal Business Goal Business Goal “building the software right” FFeFeaeatatuturureresess FFeEeaxatatumurrepesless Low level speLcoifiwc aletvioenl s speLcoifiwc alteivoenls specifications Executable specifications spock RSpec Low level specifications Low level specifications Low level specifications Low level specifications Low level specifications We use low-‐level BDD or TDD tools to define the behavior of components, classes etc. #DV14 #bddinaction @wakaleo
- 48. “building the software right” Acceptance criteria tell us what we need to build… #DV14 #bddinaction @wakaleo
- 49. “building the software right” What would we like the API to look like? #DV14 #bddinaction @wakaleo
- 50. “building the software right” Then write low-‐level specifica@ons for the code #DV14 #bddinaction @wakaleo
- 51. “building the software right” These low level specifica@ons become technical documenta@on for your APIs #DV14 #bddinaction @wakaleo
- 52. Demo #DV14 #bddinaction @wakaleo
- 53. What tool should I use? #DV14 #bddinaction @wakaleo
- 54. Collaboration before Automation “Having the conversaDon is more important than recording the conversaDon is more important than automaDng the conversaDon” -‐ Liz Keogh #DV14 #bddinaction @wakaleo
- 55. Know your audience #DV14 #bddinaction @wakaleo
- 56. High-level BDD Reporting for non-developers as well as developers Communicate about features that business owners will understand and find meaningful Higher automation and maintenance costs … #DV14 #bddinaction @wakaleo
- 59. + Groovy #DV14 #bddinaction @wakaleo
- 60. (Previously known as “Thucydides”) Living documentation Requirements reporting Encourages good test architecture Good WebDriver integration Works with other BDD tools #DV14 #bddinaction @wakaleo
- 61. + #DV14 #bddinaction @wakaleo
- 62. + #DV14 #bddinaction @wakaleo
- 63. A high-‐level BDD tool should Produce business-‐readable results Fit smoothly into your build pipeline Integrate with your development infrastructure Allow developers to collaborate with testers to implement and refactor the automa9on code #DV14 #bddinaction @wakaleo
- 64. Tips for more effec@ve BDD Test Automa@on #DV14 #bddinaction @wakaleo
- 65. Tip #1 - Use Layers Business Rules Business Flow Page/Component interac9ons Page/Component details #DV14 #bddinaction @wakaleo
- 66. Tip #2 - Favour non-UI tests where possible #DV14 #bddinaction @wakaleo
- 67. Tip #3 - Know when not to automate This slide is left intentionally blank
- 68. Low-level BDD Technical documentation for other developers Implementation details that business owners may not be interested in Faster to write and easier to maintain spock RSpec #DV14 #bddinaction @wakaleo
- 69. Low-level BDD Good naming conven9ons are the first step towards BDD #DV14 #bddinaction @wakaleo
- 70. Low-level BDD spock RSpec Readable executable specifica9ons in Groovy #DV14 #bddinaction @wakaleo
- 71. Low-level BDD spock RSpec Great support for data-‐driven tests
- 72. Low-level BDD spock RSpec Powerful and light-‐weight stubbing and mocking
- 73. Low-level BDD spock RSpec Makes very readable specifica9ons
- 74. Low-level BDD Lambda-Behave Low-‐level BDD library for Java 8 #DV14 #bddinaction @wakaleo
- 75. Low-level BDD Lambda-Behave Data-‐driven specifica9ons
- 76. Low-level BDD Lambda-Behave Generated test data
- 77. A low-‐level BDD tool should Be highly readable Be developer-‐friendly Make it easy to think in terms of specifica9ons, not tests Encourage fast feedback cycles You may need several! #DV14 #bddinaction @wakaleo
- 78. Demo #DV14 #bddinaction @wakaleo
- 79. There’s more where this came from! http://jbehave.org/ http://serenitybdd.com https://code.google.com/p/spock/ #DV14 #bddinaction @wakaleo
- 80. There’s more where this came from! And look for more material on parleys.com! #DV14 #bddinaction @wakaleo
- 81. Thank You #DV14 #bddinaction @wakaleo