Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Outside-in Test Driven Development - the London School of TDD

185 vues

Publié le

Workshop slides for "Outside-in Test Driven Development - die Londoner Schule des TDD" @ Software Quality Days 2019.
In Outside-In (London school, top-down or "mockist TDD") you build the system from the "outside-in", following the user interaction through all the parts of the system. You start with the interactions and collaborators upfront (especially those at top levels), mocking necessary dependencies (or creating fake implementations). With every finished component, you move to the previously mocked collaborators and start with TDD again there, creating actual implementations (which, even though used, were not needed before thanks to abstractions).

Publié dans : Technologie
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Outside-in Test Driven Development - the London School of TDD

  1. 1. Outside-in Test Driven Development (London School TDD) Software Quality Days 2019 Peter Kofler, ‘Code Cop’ @codecopkofler www.code-cop.org Copyright Peter Kofler, licensed under CC-BY.
  2. 2. Peter Kofler • Ph.D. (Appl. Math.) • Professional Software Developer for 20 years • “fanatic about code quality” • Independent Code Quality Coach PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY
  3. 3. I help development teams with PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY ● Professionalism ● Quality and Productivity ● Continuous Improvement
  4. 4. Mentoring PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY ● Pair Programming ● Programming Workshops ● Deliberate Practice, e.g. Coding Dojos
  5. 5. Developing Quality Software Developers
  6. 6. Agenda ● Recap Classic TDD ● Introduction Outside-in TDD ● Coding Exercise ● “Bank OCR“ ● Retrospective PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY
  7. 7. Test Driven Development
  8. 8. Your experience with TDD? ● When and how are you applying TDD? ● What are you using every day? ● Any problems? PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY
  9. 9. Test-Driven Development is ● a programming practice in which all production code is written in response to a failing test. ● a practice for designing and coding software applications. ● not a replacement for testing. PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY
  10. 10. Nathaniel Pryce, http://www.doc.ic.ac.uk/~np2/teaching/ Red Green Refactor
  11. 11. TDD Cycle ● add a test ● run all tests and see if the new one fails ● write little code ● run all tests and see them succeed ● refactor code mercilessly ● repeat PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY
  12. 12. Uncle Bob’s 3 Laws of TDD ● You are not allowed to write any ... ● … production code unless to make a failing test pass. ● … more of a unit test than is sufficient to fail the test. ● … more production code than is sufficient to pass the test. PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd
  13. 13. How do we design using TDD? PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY
  14. 14. e.g. Scanning Numbers PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY Scanner NumberScanner DigitScanner ● We need to scan documents. ● Documents contain numbers. ● Numbers consist of digits.
  15. 15. “Chicago” School TDD PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY
  16. 16. Scanning Numbers #1 PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY Scanner NumberScanner DigitScanner ● Classic TDD aka “Chicago” or “Detroit School” ● Inside-out = working from „bottom“ up
  17. 17. Scanning Numbers #2 PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY Scanner NumberScanner DigitScannerTest
  18. 18. Scanning Numbers #3 PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY Scanner NumberScanner DigitScannerTest Test
  19. 19. Scanning Numbers #4 PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY Scanner NumberScanner DigitScannerTest Test Test
  20. 20. Summary of Classic TDD  Working from „bottom“ up  Collaborators usually not mocked (just used)  State-based tests  Emergent design during refactoring  Avoids over-engineering PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY Franziska Sauerwein, http://slides.com/franziskasauerwein/outside#/
  21. 21. “London” School TDD PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY
  22. 22. Scanning Numbers #1 PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY Scanner NumberScanner DigitScanner ● Mockist TDD aka “London School” ● Outside-in = following the user interaction
  23. 23. Outside-In ● build the system from the "outside-in" ● helps identify top level function/class, entry point to the desired functionality, ● e.g. widget in GUI, link on a web page, or command line flag ● following the user interaction through all the parts of the system PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY
  24. 24. Scanning Numbers #2 PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY Scanner NumberScanner DigitScanner Test Mock
  25. 25. Mock Scanning Numbers #3 PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY Scanner NumberScanner DigitScanner Test Mock Test
  26. 26. Mock Mock Scanning Numbers #4 PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY Scanner NumberScanner DigitScannerTest Test Test
  27. 27. Summary of Outside-In TDD  Working from „outside“ in.  Assume collaborators and mock them.  Verify behaviour, not state.  Design in Red stage.  Follow Tell-Don't-Ask principle. PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY Franziska Sauerwein, http://slides.com/franziskasauerwein/outside#/
  28. 28. What is a “Mock”?
  29. 29. Five Types of Test Doubles ● Dummy (Object) ● Fake (Object) ● Stub ● Partial Stub ● Spy ● Mock ● Partial Mock ● Test-Specific Subclass PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY
  30. 30. How to “Mock” an Object ● by hand ● implement its interface (Eclipse Ctrl-1) ● subclass it (beware complex constructors) ● with java.lang.reflect.Proxy ● since Java 1.3 ● only for interfaces ● nasty for more than 1 method PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY
  31. 31. Mocking Frameworks ● e.g. Mockito, moq, Sinon.JS, ... ● mock interfaces (Proxy) ● mock non final classes (cglib) import static org.easymock.EasyMock.*; SomeInt mock = createMock(SomeInt.class); expect(mock.someMethod("param")).andReturn(42); replay(mock); // run the test which calls someMethod once verify(mock); PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY
  32. 32. Double Loop TDD PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY
  33. 33. Nathaniel Pryce, http://www.doc.ic.ac.uk/~np2/teaching/ Red Green Refactor
  34. 34. Write a failing end-to-end test Nathaniel Pryce, http://www.doc.ic.ac.uk/~np2/teaching/
  35. 35. Double Loop TDD Design Process ● create an Acceptance/Guiding Test (red) ● start with top level interaction (from UI) ● discover/design needed collaborators ● stub/mock these dependencies ● implement using TDD ● run Guiding Test to see where to go next ● while Guiding Test is still red ● move down to previously mocked collaborator PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY Emily Bache, http://coding-is-like-cooking.info/2013/04/outside-in-development-with-double-loop-tdd/
  36. 36. Scanner NumberScanner DigitScanner Scanning Numbers #1 PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY Scanner NumberScanner DigitScanner Guiding Test
  37. 37. Scanner NumberScanner DigitScanner Scanning Numbers #2 PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY Scanner NumberScanner DigitScanner Test Mock Guiding Test
  38. 38. Scanner NumberScanner DigitScanner Scanning Numbers #3 PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY Scanner NumberScanner DigitScanner Test Mock Guiding Test
  39. 39. Mock Scanner NumberScanner DigitScanner Scanning Numbers #4 PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY Scanner NumberScanner DigitScanner Mock Test Guiding Test Test
  40. 40. Mock Scanner NumberScanner DigitScanner Scanning Numbers #5 PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY Scanner NumberScanner DigitScanner Mock Test Guiding Test Test
  41. 41. Mock Mock Scanner NumberScanner DigitScanner Scanning Numbers #6 PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY Scanner NumberScanner DigitScannerTest Guiding Test Test Test
  42. 42. Mock Mock Scanner NumberScanner DigitScanner Scanning Numbers #7 PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY Scanner NumberScanner DigitScannerTest Guiding Test Test Test
  43. 43. Try it yourself PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY
  44. 44. Coding Dojo Mindset ● Safe place outside work ● We are here to learn ● Need to slow down ● Focus on doing it right ● Collaborative Game PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY
  45. 45. Assignment PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY
  46. 46. Bank OCR ● You work for a bank, which has a machine to assist in reading letters. The machine scans the paper documents, and produces a file with a number of entries which each look like this: ····_··_·····_··_··_··_··_· ··|·_|·_||_||_·|_···||_||_| ··||_··_|··|·_||_|··||_|·_| ● Each entry is 4 lines long, each line has 27 characters. The first 3 lines contain an account number written using pipes and underscores, and the fourth line is blank. Each account number should have 9 digits, all of which should be in the range 1-9. ● Write a program that can take this file and parse it into actual account numbers. PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY
  47. 47. Prepare ● Find a pair. ● Agree on a programming language. ● Get the project from https://bitbucket.org/pkofler/bankocr-kata-setup ● See GuidingTest (failing test) ● Guiding Test is the starting point. ● Work through outer API, outside-in. ● Implement Bank OCR. PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY
  48. 48. Recommended: A Test List ● Use first ten minutes to create list of acceptance test cases (on paper) ● Start each TDD cycle with at least three test cases before beginning to code (paper or text file) PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY
  49. 49. Apply: Outside-In TDD ● build the system from the "outside-in", following the user interaction through all the parts of the system ● create a Guiding Test ● start with top level interactions ● mock dependencies ● implement using TDD until all tests green ● move inside previously mocked collaborator PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY
  50. 50. Don't Focus on Getting it Done. F0cus on Doing It Perfectly.
  51. 51. Practice
  52. 52. Closing Circle ● What did you learn today? ● What surprised you today? ● What will you do differently in the future? PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY
  53. 53. Study! ● TDD is important. ● You need to study it. ● Good books: PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY
  54. 54. Peter Kofler @codecopkofler www.code-cop.org PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY
  55. 55. CC Images ● London https://www.flickr.com/photos/damski/8019978119 ● Bruce http://www.flickr.com/photos/sherpas428/4350620602/ ● pairing http://www.flickr.com/photos/dav/94735395/ ● agenda http://www.flickr.com/photos/24293932@N00/2752221871/ ● wants you http://www.flickr.com/photos/shutter/105497713/ ● drawing https://www.flickr.com/photos/msk13/4108489367 ● Chicago https://www.flickr.com/photos/pedrosz/34886261555/ ● mocks http://www.flickr.com/photos/sneddon/2413980712/ ● loops https://www.flickr.com/photos/fitzharris/7592626086/ ● hands https://www.flickr.com/photos/ninahiironniemi/497993647/ ● dojo http://www.flickr.com/photos/49715404@N00/3267627038/ ● bank https://www.flickr.com/photos/bigmacsc99/4325336251 PETER KOFLER, CODE-COP.ORG FANATIC ABOUT CODE QUALITY

×