Using BDD with TDD, Explained!

Short movie on BDD and TDD - http://bit.ly/2w7PYmf

A concise explanation and demonstration of Behavior-Driven Development and Test-Driven Development, in practice.

Note: During this presentation we established a mobbing session to create a rudimentary conference session feedback app, in real-time.

Github Repo: https://github.com/Bill-A/Correctness-DrivenDevelopment

Transcript

1. © 2017, Bill Allen / Kieran Murphy. All Rights Reserved. #BDD-TDD 1 Using BDD with TDD, Explained!
2. © 2017, Bill Allen / Kieran Murphy. All Rights Reserved. #BDD-TDD 2 Bill Allen - agile Innovation Labs Bill@agileInnov.com linkedin.com/in/agilebillallen/ Kieran Murphy - ThoughtWorks KiMurphy@ThoughtWorks.com linkedin.com/in/kieranmurphycode
3. © 2017, Bill Allen / Kieran Murphy. All Rights Reserved. #BDD-TDD BILL’S TOP FIVE REASONS TO USE BDD 1. Drives collaboration and communication between business and development team. 2. Provides a common language for the whole-team to understand what is being developed. 3. Allows Business to have quantitative insight on the progress of development and answer to the question, “What can the software do?” 4. Enables the design of interfaces to be explored (experimented upon) early on. 5. Increased value! Ability to achieve the right outcomes without unnecessary output (waste). 3
4. © 2017, Bill Allen / Kieran Murphy. All Rights Reserved. #BDD-TDD KIERAN’S TOP FIVE REASONS TO USE TDD 1. Improved technical architecture - SOLID Principles come for free 2. Results in the least amount of code possible to get the job done 3. Software built from a process of constant incremental change is easy to change later 4. Fosters collaboration and transparency among developers, QA, immediate business stakeholders and management 5. Very satisfying practice 4
5. © 2017, Bill Allen / Kieran Murphy. All Rights Reserved. #BDD-TDD 5 Roadmap for this 100 minute Journey See BDD with TDD Hear BDD with TDD Do BDD with TDD
6. © 2017, Bill Allen / Kieran Murphy. All Rights Reserved. #BDD-TDD 6 SEE: a first-look at Behavior-Driven Development with Test-Driven Development
7. © 2017, Bill Allen / Kieran Murphy. All Rights Reserved. #BDD-TDD http://bit.ly/2w7PYmf 7
8. © 2017, Bill Allen / Kieran Murphy. All Rights Reserved. #BDD-TDD 8 HEAR: TDD, BDD, ATDD … Explained
9. © 2017, Bill Allen / Kieran Murphy. All Rights Reserved. #BDD-TDD 9 They are not testing practices. BDD / ATDD are Whole Team analysis. TDD is a developer designing, before coding the solution. Quality Assurance Test Engineer Business Analyst Product Manager Product Owner Developer

10. © 2017, Bill Allen / Kieran Murphy. All Rights Reserved. #BDD-TDD 10 Test-Driven Development (TDD) *from Test-Driven Development by Example - Kent Beck 1.Red - Write a little test that doesn’t work, and perhaps doesn’t even compile at first. 2.Green - Make the test work quickly, committing whatever sins necessary in process. 3.Refactor - Eliminate all of the duplication created in merely getting the test to work. Red/green/refactor – the TDD mantra. (preface, p.x) In other chapter the same order is described as “general TDD cycle”: 1.Write a test… 2.Make it run… 3.Make it right… The goal is clean code that works (thanks to Ron Jeffries for this concise summary)… First we’ll solve the “that works” part of the problem. Then we’ll solve the “clean code” part. (p.11)
11. © 2017, Bill Allen / Kieran Murphy. All Rights Reserved. #BDD-TDD Behavior Driven Development (BDD) Developed by Dan North and Chris Matts, 2003 - 2004, published 2006 “While using and teaching agile practices like test-driven development...Programmers wanted to know where to start, what to test and what not to test, how much to test in one go, what to call their tests, and how to understand why a test fails.”* “I found the shift from thinking in tests to thinking in behaviour so profound that I started to refer to TDD as BDD, or behaviour- driven development.”* “If we could develop a consistent vocabulary for analysts, testers, developers, and the business, then we would be well on the way to eliminating some of the ambiguity and miscommunication that occur when technical people talk to business people.”* “BDD is a second-generation, outside-in, pull-based, multiple-stakeholder, multiple-scale, high- automation, agile methodology”** * Dan North, “Introducing BDD”: https://dannorth.net/introducing-bdd/ ** Dan North, “Agile Testing, Specifications and BDD Exchange”, 2009 11
12. © 2017, Bill Allen / Kieran Murphy. All Rights Reserved. #BDD-TDD 12 *Origins (from Agile Alliance web site) 2003: Kent Beck briefly mentions ATDD in the book "Test Driven Development: By Example" but dismisses it as impractical. 2003 to 2004: driven by the popularity of Fit/FitNesse ATDD becomes accepted practice in spite of Beck's objections. ATDD involves team members with different perspectives (customer, development, testing) collaborating to write acceptance tests in advance of implementing the corresponding functionality. Customer perspectives
 …what problem are we trying to solve? Development perspectives
 …how might we solve this problem? Testing perspectives
 …what about…? Acceptance Test-Driven Development (ATDD)
13. © 2017, Bill Allen / Kieran Murphy. All Rights Reserved. #BDD-TDD 13 * David Hussman, DevJam, Minneapolis,MN “BDD is TDD people who finally discovered a lamer version of ATDD. In the end they are all just more noisy label to spin on and around. I tend to think of these spaces as: • Developer tes+ng (by the geeks for the design) – they tell the story of the code • Story tes)ng (by the community for the product) – they tell the story of the product” Email conversation with David back in 2012
14. © 2017, Bill Allen / Kieran Murphy. All Rights Reserved. #BDD-TDD 14 DO: BDD with TDD … Introducing Mobbing
15. © 2017, Bill Allen / Kieran Murphy. All Rights Reserved. #BDD-TDD Mobbing, using the ATDD cycle 15
16. © 2017, Bill Allen / Kieran Murphy. All Rights Reserved. #BDD-TDD Can you give me an example? What if …? Behaviors (examples) 16 How does it do that? Can you make it do …? Team needs a ubiquitous language for analysis Quality Assurance Test Engineer Business Analyst Product Manager Product Owner Developer

17. © 2017, Bill Allen / Kieran Murphy. All Rights Reserved. #BDD-TDD 17 Feature: Some terse yet descrip2ve text of what is desired Textual descrip/on of the business value of this feature Business rules that govern the scope of the feature Any addi(onal informa(on that will make the feature easier to understand Scenario: Some determinable business situa2on Given some precondi.on When some ac+on by the actor Then some testable outcome is achieved Scenario: Some other determinable business situa3on Given some precondi.on When some ac+on by the actor Then some testable outcome is achieved ... Gherkin - a formal language for specifying behaviors
18. © 2017, Bill Allen / Kieran Murphy. All Rights Reserved. #BDD-TDD Gather a cross-functional Product Team. Tell stories about a user’s experience with the conference feedback app. (Tell stories, don’t write User Stories!) Ask lots of questions: 1. Ask PO for examples of how this feature should behave. 2. Why does the feature provide value? For who? How? 3. How will you know the feature works? Discuss 18 As a team, we will develop a simple app to capture conference session feedback for the presenters. “What is the simplest manner in which attendees can use a browser to submit conference feedback?” “How do attendees submit feedback?” “What happens when an attendee submits negative feedback?” “What happens when an attendee submits positive feedback?” “What does a feedback report contain?”
19. © 2017, Bill Allen / Kieran Murphy. All Rights Reserved. #BDD-TDD Distill 19 Notes on submitting feedback: localhost:8080/feedback/positive Feature: Capture conference session feedback Submitting feedback: localhost:8080/feedback/negative Receiving feedback: localhost:8080/feedback/report Scenario: Capture Negative feedback Given The presentation has ended When I submit negative feedback Then I receive confirmation of submission And A feedback report is generated
20. © 2017, Bill Allen / Kieran Murphy. All Rights Reserved. #BDD-TDD Develop 20
21. © 2017, Bill Allen / Kieran Murphy. All Rights Reserved. #BDD-TDD 21 Demo
22. © 2017, Bill Allen / Kieran Murphy. All Rights Reserved. #BDD-TDD 22 BDD and TDD in your organization
23. © 2017, Bill Allen / Kieran Murphy. All Rights Reserved. #BDD-TDD 23 Will it solve your challenges? What can you control: Tools that are used for automation? Who performs testing? When testing is performed? Completing testing and dev in same sprint? % of manual tests in your suite? % of automated tests in your suite? Ability to perform business facing testing? BDD and TDD in your organization
24. © 2017, Bill Allen / Kieran Murphy. All Rights Reserved. #BDD-TDD Questions? 24
25. © 2017, Bill Allen / Kieran Murphy. All Rights Reserved. #BDD-TDD Resources: 25 3 2 IEEE SOFTWARE Published by the IEEE Computer Society 0740-7459/07/$25.00 © 2007 IEEE Actually, I don’t think any software developer is truly content to ship code that falls below the bar. The truth is that most developers sim- ply don’t know how to reach that bar or don’t believe reaching it is possible. All too often they commit to deadlines that they later find they can’t meet, and so, through high-stress heroics, they wind up compromising quality to avoid be- ing overly late. In this article, I’ll discuss how test-driven de- velopment can help software developers achieve a higher degree of professionalism. TDD isn’t a silver bullet and won’t suddenly transform you into a sterling professional. It does, however, play a significant role. The three laws of TDD TDD practitioners follow these three laws: ▪ You may not write production code unless you’ve first written a failing unit test. ▪ You may not write more of a unit test than is sufficient to fail. ▪ You may not write more production code than is sufficient to make the failing unit test pass. These three laws lock you into a tight loop in which you first write a portion of a unit test that fails, and then you write just enough pro- duction code to make that test pass. This loop is perhaps two minutes long and almost always ends in success.1 Following these laws perfectly doesn’t always make sense. Sometimes you’ll write a larger test. Sometimes you’ll write extra production code. Sometimes you’ll write tests after you’ve written the code to make them pass. Sometimes it’ll take more than two minutes to go around the loop. The goal isn’t perfect adherence to the laws—it’s to decrease the interval between writing tests and production code to a matter of minutes. focus Professionalism and Test-Driven Development Professional software developers ship clean, flexible code that works—on time. It seems to me that this statement is the mini- mum standard for professional behavior for software developers. Yet, in my travels as a software consultant, I’ve met many soft- ware developers who don’t set the bar this high and instead ship late, buggy, messy, and bloated code. test-driven development Robert C. Martin, Object Mentor Test-driven development is a discipline that helps professional software developers ship clean, flexible code that works, on time. Short movie on BDD and TDD: http://bit.ly/2w7PYmf repo: https://github.com/Bill-A/Correctness-DrivenDevelopment
26. © 2017, Bill Allen / Kieran Murphy. All Rights Reserved. #BDD-TDD 26 THANK YOU Bill Allen - agile Innovation Labs Bill@agileInnov.com linkedin.com/in/agilebillallen/ Kieran Murphy - ThoughtWorks KiMurphy@ThoughtWorks.com linkedin.com/in/kieranmurphycode
27. © 2017, Bill Allen / Kieran Murphy. All Rights Reserved. #BDD-TDD 
 The End 27