Test-Driven Development

Non-technical introduction to test-driven development in its broadest sense.

Topics included:
* Fractal concept: Lean/3 horizon/3X model, hypothesis-driven development
* "Developer TDD": Mockist vs. classicist
* Why do TDD?
* When to invest in TDD/test automation
* Case studies from AE customers

Transcript

1. ae nv/sa Interleuvenlaan 27b, B3001 - Heverlee T +32 16 39 30 60 F +32 16 39 30 70 www.ae.be TEST-DRIVEN DEVELOPMENT
2. WHY? http://www.indeed.com/jobtrends/test-driven+development.html
3. WHY?
4. WHY?
5. WHY? http://www.zdnet.com/article/overcome-agile-hangovers-with-a-software- craftsman-approach/
6. WHAT?
7. WHAT?
8. WHAT? https://arialdomartini.wordpress.com/2012/07/20/you-wont-believe-how-old-tdd-is/
9. STYLES OF TDD
10. STYLES OF TDD • Detroit • Bottom-up • Limited use of mocks • “Easy” • Possible rework
11. STYLES OF TDD http://blog.testdouble.com/posts/2015-09-10-how-i-use-test-doubles.html • London • Top-down • “Double-loop” TDD • Heavy use of mocks • Less straightforward • “Testing internals”
12. STYLES OF TDD http://codurance.com/2015/05/12/does-tdd-lead-to-good-design/ “Which TDD style should we use? Both. All. They are just tools and as such, they should be used according to your needs. Experienced TDD practitioners jump from one style to another without ever worrying which style they are using.”
13. LEVELS OF TDD http://lisacrispin.com/2011/11/08/using-the-agile-testing-quadrants/
14. LEVELS OF TDD http://anarchycreek.com/2009/05/20/theyre-called-microtests/
15. LEVELS OF TDD https://www.youtube.com/watch?v=njcHzGYv7nI
16. LEVELS OF TDD http://www.slideshare.net/jezhumble/lean-enterprise-42651898
17. TEST DISTRIBUTION http://martinfowler.com/bliki/TestPyramid.html
18. TEST DISTRIBUTION https://www.thoughtworks.com/insights/blog/introducing-software-testing-cupcake-anti-pattern
19. LEVELS OF TDD http://verraes.net/2015/01/economy-of-tests/
20. BUILD FOR TESTABILITY http://www.natpryce.com/articles/000772.html
21. BUILD FOR TESTABILITY
22. BUILD FOR TESTABILITY
23. WHAT TDD ISN’T
24. WHAT TDD ISN’T
25. WHAT TDD ISN’T
26. WHY?
27. WHY?
28. WHY?
29. WHY? http://www.eecs.yorku.ca/course_archive/2003- 04/W/3311/sectionM/case_studies/money/KentBeck_TDD_byexample.pdf
30. WHY?
31. WHY? https://blog.thesoftwarecraft.com/2013/11/wishful-programming.html
32. WHY NOT? http://research.microsoft.com/en-us/groups/ese/nagappan_tdd.pdf https://leanpub.com/leprechauns “The results of the case studies indicate that the pre-release defect density of the four products decreased between 40% and 90% relative to similar projects that did not use the TDD practice. Subjectively, the teams experienced a 15–35% increase in initial development time after adopting TDD.”
33. WHY NOT? http://research.microsoft.com/en-us/groups/ese/nagappan_tdd.pdf https://leanpub.com/leprechauns “The results of the case studies indicate that the pre-release defect density of the four products decreased between 40% and 90% relative to similar projects that did not use the TDD practice. Subjectively, the teams experienced a 15–35% increase in initial development time after adopting TDD.” “a survey of all of the studies that have been done on TDD have shown that the better the study done, the weaker the signal as to its benefit”
34. WHY NOT? http://codurance.com/2015/05/12/does-tdd-lead-to-good-design/ https://www.quora.com/Does-test-driven-development-TDD-really-improve-software-quality/answer/Robert-Martin-9?srid=zADr http://blog.ploeh.dk/2010/12/22/TheTDDApostate/ http://blog.jbrains.ca/permalink/tdd-is-not-magic “Any developer can make a mess regardless if they are writing tests or not. Developers can also test drive crap regardless of which TDD style they are using.” “Extremes are bad. We are going from BDUF (Big Design Up Front) to no design at all. Throwing away our design knowledge is a mistake.” “TDD does not drive us towards good design. It is not a design technique. I still write code test-first because I find it more productive, but I make design decisions out of band.” “TDD is not magic. The rules themselves do not guarantee success. You have to keep the brain switched on.”
35. WHEN?
36. WHEN?
37. WHEN?
38. WHEN? https://leanpub.com/wewut
39. WHEN? https://vimeo.com/68375232
40. WHEN? http://shop.oreilly.com/product/0636920030355.do
41. CASE STUDIES
43. TRADEROUTER
44. TRADEROUTER 32,93% 32,64% 41,76% 41,52% 33,63% 31,92% 27,95% 31,15% 35,22% 36,08% 36,08% 35,79% 37,32% 35,24% 34,41% 35,55% 35,00% 33,18% 33,14% 22,00% 24% 24% 28% 25% 29% 0% 5% 10% 15% 20% 25% 30% 35% 40% 45% 50% 55% 60% 65% 70% 75% 80% 85% 90% 95% 100% 10/1… 31/1… 21/0… 11/0… 4/03… 25/0… 15/0… 6/05… 27/0… 17/0… 8/07… 29/0… 19/0… 9/09… 30/0… 21/1… 11/1… 2/12… 23/1… 13/0… 3/02… 24/0… 17/0… 7/04… 28/0… 19/0… 9/06… 30/0… 21/0… 11/0… 1/09… 22/0… 13/1… 3/11… 24/1… 15/1… 5/01… 26/0… 16/0… 9/03… 30/0… 20/0… 11/0… 1/06… 22/0… 13/0… 3/08… Code Coverage Date TRADZSTER: % covered Total
45. TRADEROUTER
46. TRADEROUTER
47. TRADEROUTER
48. TRADEROUTER
50. REFERENCE DATA @ TEST-AANKOOP
51. REFERENCE DATA @ TEST-AANKOOP
52. REFERENCE DATA @ TEST-AANKOOP 4 E2E tests against public API
53. REFERENCE DATA @ TEST-AANKOOP 15 fast acceptance tests (in-memory, no WCF, no DB)
54. REFERENCE DATA @ TEST-AANKOOP 11 focused integration tests for persistence
55. REFERENCE DATA @ TEST-AANKOOP 84 hyper-focused blazing-fast unit tests
56. REFERENCE DATA @ TEST-AANKOOP 84 unit 15 acceptance + 11 data 4 E2E against public API
57. REFERENCE DATA @ TEST-AANKOOP 84 unit 15 acceptance + 11 data 4 E2E against public API 5s 2s 7s <1s
58. REFERENCE DATA @ TEST-AANKOOP
60. DGZ “Testing is overhead” “Developers should spend time coding”
61. DGZ • New greendfield project • 10 KLOC production code • 5+ KLOC test code • Lead by example • Consistent quality • Code review / pair programming • Guerilla implementation • 2 years @ DGZ • Prepare for tough questions • How much longer will features take? • QA out of a job? • Where do we start?
62. DGZ http://blog.thecodewhisperer.com/2014/09/28/surviving-legacy-code-with-golden-master-and- sampling/
63. DGZ 250 unit 10 integration + 10 data 30 E2E regression
64. TITAN @ FLUXYS
65. QUALITY @ YOUR ACCOUNT • Can developers suggest/implement design improvements during development of a feature? • How many tasks come back after being rejected by seperate QA team? • How long does it take for a change on a single line of code • To be “done”? • To be pushed to production? • Can you trace lines of code back to features/business value? • How much time do devs spend • Writing tests? • Fixing tests?
67. ae.be