Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

TDD Trade-Offs @Softwerkskammer Karlsruhe

175 Aufrufe

Veröffentlicht am

Vortrag bei der Softwerkskammer Karlsruhe

Abstract:
Unter TDD-Praktikern haben sich verschiedene Schulen herausgebildet: Die "Mockists" ("London School“) auf der einen Seite fokussieren auf die Interaktionen der Objekte und ermöglichen durch starken Mocking-Einsatz, diese isoliert Unit-testen zu können. Die "Classicists" ("Chicago School") auf der anderen Seite versuchen hingegen Mocking soweit möglich zu vermeiden. Zusätzlich dazu hat David in den letzen Jahren mit dem "Fake it Outside-In TDD" noch eine weitere Alternative entwickelt, die besonders dabei hilft in sehr kleinen "Baby Steps" zu arbeiten.

Bei näherem Vergleich der Schulen entpuppt sich eine naive "entweder-oder-Entscheidung" als viel zu eindimensional. Statt dessen existieren parallel verschiedene unabhängige Dimensionen. Um zu verstehen, welche Variante in welchem Kontext besser funktioniert, werden die zugrunde liegenden Trade-Offs der einzelnen Dimensionen analysiert und herausgearbeitet, welche Kriterien bei der Entscheidungsfindung helfen können.

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

TDD Trade-Offs @Softwerkskammer Karlsruhe

  1. 1. TDD-Trade-Offs Softwerkskammer Karlsruhe David Völkel 09.04.2019
  2. 2. @davidvoelkel @softwerkskammer @codecentric TDD & Design
  3. 3. 1.TDD-Trade-Offs 2."Outside-In Fake It TDD" Deep Dive AGENDA
  4. 4. CLASSICIST & MOCKISTS?
  5. 5. MOCKISTS?
  6. 6. ● „London School“: 
 Steve Freeman, Nat Pryce ● XP 2000 paper 
 „Endo-Testing: 
 Unit Testing with Mock Objects “ ● OOPSLA 2004 
 „Mock Roles, not Objects“ ● „Growing Object Oriented Software“ #GOOS 2009 MOCKISTS
  7. 7. ● Problem 
 Zu viele integrierte Tests
 => Isoliert testen ● Mocks [& Interfaces] ● Behaviour Verification ● Outside-In Design MOCKISTS
  8. 8. CLASSICISTS?
  9. 9. “Chicago“ oder “Detroit School“: 
 Kent Beck, Uncle Bob, Ron Jeffries, … CLASSICISTS
  10. 10. Weniger Mocks, • nur an Prozessgrenze • mehr Integrierte Tests CLASSICISTS
  11. 11. Weniger Mocks, • nur an Prozessgrenze • mehr Integrierte Tests Design • bottom up vs emergent CLASSICISTS
  12. 12. DESIGN DIMENSIONEN Unsicherheit Isolation Richtung Komplexität
  13. 13. UNSICHERHEIT Design Dimension
  14. 14. Akzeptanztest 
 DESIGN UNKLAR?
  15. 15. Akzeptanztest 
 DESIGN UNKLAR?
  16. 16. Akzeptanztest 
 DESIGN UNKLAR?
  17. 17. Akzeptanztest 1. Pass the Tests 2. Reveal Intention & No Duplication 3. Fewest Elements 
 4 RULES OF 
 SIMPLE DESIGN "BeckDesignRules", Martin Fowler
  18. 18. Akzeptanztest 1. Pass the Tests 2. Reveal Intention & No Duplication 3. Fewest Elements 
 4 RULES OF 
 SIMPLE DESIGN
  19. 19. Akzeptanztest 
 EMERGENT DESIGN
  20. 20. Akzeptanztest 
 EMERGENT DESIGN
  21. 21. + Wenn Design unklar + Refaktorierbarkeit 
 EMERGENT DESIGN
  22. 22. + Wenn Design unklar + Refaktorierbarkeit - Aufwändig - Integrierte Tests 
 EMERGENT DESIGN
  23. 23. DESIGN* UNSICHER SICHER Emergent beim Refactoring "Up-Front" beim Test-Schreiben Integrationstest als ganzes Grün bekommen Outside-In oder Bottom-Up * Intra-Object Design
  24. 24. 
 
 
 
 RICHTUNG
 Design Dimension Outside-In vs Bottom-Up / Inside-Out
  25. 25. GUI Adapter DRITTSERVICE 3rd Party Service
  26. 26. GUI Adapter DRITTSERVICE TREIBT 3rd Party Service
  27. 27. Integrations Test Adapter 3rd Party Service BOTTOM UP
  28. 28. Test 3rd Party Service BOTTOM UP
  29. 29. BOTTOM-UP Sweet spots Drittsystem treibt Design Wenn Design sehr klar YAGNI Design Potential!
  30. 30. ıINSIDE-OUT WENIG SINNVOLL 3rd Party Service GUI Domain-Service Service-Client Adapterlayer ("Outside")
  31. 31. Akzeptanz-Test GUI / Endpoint TOP-DOWN / "OUTSIDE-IN"
  32. 32. Unittest Mock OUTSIDE-IN
 MOCKING
  33. 33. Test OUTSIDE-IN
 MOCKING
  34. 34. GUI / Endpoint Akzeptanztest OUTSIDE-IN
 FAKE-IT
  35. 35. Fake Akzeptanztest OUTSIDE-IN
 FAKE-IT
  36. 36. Fake Akzeptanztest Fake OUTSIDE-IN
 FAKE-IT
  37. 37. Unittest Akzeptanztest OUTSIDE-IN
 FAKE-IT
  38. 38. Akzeptanztest OUTSIDE-IN
 FAKE-IT
  39. 39. 
 
 OUTSIDE-IN
 Passgenaues Design Mocks vs Fake It
  40. 40. 
 
 
 
 ISOLATION
 Design Dimension Mocks vs Integrierte Tests
  41. 41. aufwendiges Setup Fehlerfindung # Testfällen Langsames Feedback Refactorability sinkt Isolationsaufwand Zu wenig Nutzen Lesbarkeit 
 
 TRADE-OFF
 ZU GROSS vs ZU KLEIN
  42. 42. INTEGRATION OPERATION SEGREGATION PRINCIPLE *"Integration Operation Segregation Principle", Ralf Westphal "Die kniffligen Fälle beim Testen - Sichtbarkeit", Stefan Lieser *
  43. 43. INTEGRATION OPERATION SEGREGATION PRINCIPLE public void sendDiscountMailingTo(String email) { Customer customer = customerDB.findCustomerBy(email); Account account = customer.account(); String discount = account == FREE ? "no" : account == BASE ? "a 10%" : account == PREMIUM ? "a 25%" : "-ERROR-"; String content = "Hello " + customer.getName() + ",nn" + "This week you get " + discount + " discount " + "on all our products.nn" + "Best Regards,n" + "ACME Customer Service"; mailService.sendMail(email, content); }
  44. 44. OPERATION public void sendDiscountMailingTo(String email) { Customer customer = customerDB.findCustomerBy(email); Account account = customer.account(); String discount = account == FREE ? "no" : account == BASE ? "a 10%" : account == PREMIUM ? "a 25%" : "-ERROR-"; String content = "Hello " + customer.getName() + ",nn" + "This week you get " + discount + " discount " + "on all our products.nn" + "Best Regards,n" + "ACME Customer Service"; mailService.sendMail(email, content); } INTEGRATION OPERATION SEGREGATION PRINCIPLE
  45. 45. INTEGRATION INTEGRATION OPERATION public void sendDiscountMailingTo(String email) { Customer customer = customerDB.findCustomerBy(email); Account account = customer.account(); String discount = account == FREE ? "no" : account == BASE ? "a 10%" : account == PREMIUM ? "a 25%" : "-ERROR-"; String content = "Hello " + customer.getName() + ",nn" + "This week you get " + discount + " discount " + "on all our products.nn" + "Best Regards,n" + "ACME Customer Service"; mailService.sendMail(email, content); } INTEGRATION OPERATION SEGREGATION PRINCIPLE
  46. 46. INTEGRATION OPERATION SEGREGATION PRINCIPLE INTEGRATION INTEGRATION OPERATION public void sendDiscountMailingTo(String email) { Customer customer = customerDB.findCustomerBy(email); Account account = customer.account(); String discount = account == FREE ? "no" : account == BASE ? "a 10%" : account == PREMIUM ? "a 25%" : "-ERROR-"; String content = "Hello " + customer.getName() + ",nn" + "This week you get " + discount + " discount " + "on all our products.nn" + "Best Regards,n" + "ACME Customer Service"; mailService.sendMail(email, content); }
  47. 47. OPERATION INTEGRATION public void sendDiscountMailingTo(String email) { Customer customer = customerDB.findCustomerBy(email); String content = renderMessage(customer, customer.account()); mailService.sendMail(email, content); } private String renderMessage(Customer customer, Account account) { String discount = account == FREE ? "no" : account == BASE ? "a 10%" : account == PREMIUM ? "a 25%" : "-ERROR-"; return "Hello " + customer.getName() + ",nn" + "This week you get " + discount + " discount " + "on all our products.nn" + "Best Regards,n" + "ACME Customer Service"; } INTEGRATION OPERATION SEGREGATION PRINCIPLE
  48. 48. public void sendDiscountMailingTo(String email) { Customer customer = customerDB.findCustomerBy(email); String content = renderMessage(customer, customer.account()); mailService.sendMail(email, content); } private String renderMessage(Customer customer, Account account) { String discount = account == FREE ? "no" : account == BASE ? "a 10%" : account == PREMIUM ? "a 25%" : "-ERROR-"; return "Hello " + customer.getName() + ",nn" + "This week you get " + discount + " discount " + "on all our products.nn" + "Best Regards,n" + "ACME Customer Service"; } TESTS?
  49. 49. OPERATION public void sendDiscountMailingTo(String email) { Customer customer = customerDB.findCustomerBy(email); String content = renderMessage(customer, customer.account()); mailService.sendMail(email, content); } private String renderMessage(Customer customer, Account account) { String discount = account == FREE ? "no" : account == BASE ? "a 10%" : account == PREMIUM ? "a 25%" : "-ERROR-"; return "Hello " + customer.getName() + ",nn" + "This week you get " + discount + " discount " + "on all our products.nn" + "Best Regards,n" + "ACME Customer Service"; } TESTS? N UNITTESTS
  50. 50. INTEGRATION OPERATION public void sendDiscountMailingTo(String email) { Customer customer = customerDB.findCustomerBy(email); String content = renderMessage(customer, customer.account()); mailService.sendMail(email, content); } private String renderMessage(Customer customer, Account account) { String discount = account == FREE ? "no" : account == BASE ? "a 10%" : account == PREMIUM ? "a 25%" : "-ERROR-"; return "Hello " + customer.getName() + ",nn" + "This week you get " + discount + " discount " + "on all our products.nn" + "Best Regards,n" + "ACME Customer Service"; } TESTS?1 INTEGRATION TEST (or MOCKING TEST) N UNITTESTS
  51. 51. 
 
 
 MOCKING
 SWEETSPOTS

  52. 52. CONDITIONAL INTERACTIONS Mocking when IOSP not possible public String signup(String username) throws Exception { if(userDB.findUserBy(username) == null) { userDB.createUser(new User(username)); return "Welcome " + username; } else { return "Username ' " + username + "' " + "already taken, please choose another"; } } 
 
 BEDINGTE INTERAKTION
 
 
 

  53. 53. SYSTEM GRENZEN 3rd Party Service Adapter
  54. 54. SYSTEM GRENZEN 3rd Party Service Mock
  55. 55. KOMPLEXITÄÄAET Design Dimension Triangulation vs. Fake It
  56. 56. GREEN BAR PATTERNS* Obvious Implementation Fake it (until you make it) Triangulation * Kent Beck in "TDD by Example"
  57. 57. GREEN BAR PATTERNS Obvious Implementation Fake it Triangulation Trade-Off Complexity
  58. 58. GREEN BAR PATTERNS DEMO
  59. 59. SWEET SPOT Trivial GREEN BAR PATTERNS Obvious Implementation Fake it Triangulation
  60. 60. SWEET SPOT Trivial Structure GREEN BAR PATTERNS Obvious Implementation Fake it Triangulation
  61. 61. SWEET SPOT Trivial Structure Logic GREEN BAR PATTERNS Obvious Implementation Fake it Triangulation
  62. 62. DESIGN* SICHER UNSICHER Outside-In Mockist Outside-In Fake It Bottom-Up Emergent 
 (Triangulation per Akzeptanztests) * Intra-Object Design Treiber Richtung Führung Komplexität Isolation
  63. 63. ENTARTUNGEN Kein TDD? Keine Akzeptanztests?
  64. 64. if (unsicher) Emergent else if (drittsys) Bottom-Up else if (isoliert) Outside-In MOCKIST else Outside-In Fake-It CLASSICIST
  65. 65. MOCKIST
 ODER 
 CLASSICIST?
 

  66. 66. MOCKIST
 ODER 
 CLASSICIST?
 
 KOMBINIEREN!
 

  67. 67. MOCKIST
 ODER 
 CLASSICIST?
 
 KOMBINIEREN!
 TRADE-OFFS!

  68. 68. OUTSIDE-IN FAKE IT DEEP DIVE
  69. 69. OUTSIDE-IN FAKE IT INTEGRATION Fake It Triangulation OPERATION Start with • comprehensive 
 Acceptance Test • faked result Drive structure by refactoring Drive logic by unit tests
  70. 70. OUTSIDE-IN FAKE IT INTEGRATION Fake It Triangulation OPERATION Start with • comprehensive 
 Acceptance Test • faked result Drive structure by refactoring Drive logic by unit tests
  71. 71. PREPARATORY REFACTORINGS* *"An example of preparatory refactoring", Martin Fowler
  72. 72. PREPARATORY REFACTORINGS* *"An example of preparatory refactoring", Martin Fowler
  73. 73. "GREEN" PHASE TRIANGULATION Implementation Run Test "Green Phase"
  74. 74. LIMIT YOUR TIME IN RED "Green Phase" Implementation Run Test
  75. 75. LIMIT YOUR TIME IN RED "Green Phase" Implementation Run Test Implementation Run TestPreparatory Refactoring
  76. 76. PREPARATORY REFACTORINGS DEMO
  77. 77. CALCULATE BACKWARDS DEMO
  78. 78. DIAMOND KATA
  79. 79. FAKE IT OUTSIDE-IN DEMO
  80. 80. DATA GUIDES STRUCTURE Triangulation Fake It Structure Cumbersome Data guides well
  81. 81. # BRANCHES Triangulation Fake It # N 1 More confidence More effort
  82. 82. # BRANCHES Triangulation Fake It # N 1 Fake data easy to forget Omitting cases is tempting
  83. 83. TIME IN GREEN Triangulation Prep Refactoring Triangulation Fake It
  84. 84. WHY? Outside-In => YAGNI free design Without mocking drawbacks
  85. 85. WHY? Outside-In => YAGNI free design Without mocking drawbacks Vs Triangulation More time in GREEN Better Design Guidance
  86. 86. QUELLEN • "Growing Object Oriented Systems", 
 Nat Pryce, Steve Freeman • "Mocks Aren't Stubs", 
 Martin Fowler • "Integration Operation Segregation Principle", 
 Ralf Westphal • „Die kniffligen Fälle beim Testen – Sichtbarkeit“, 
 Stefan Lieser • "Fake It Outside-In TDD"
 David Völkel
  87. 87. Q&A ?!
  88. 88. Licence Creative Commons Attribution-ShareAlike 3.0
  89. 89. IMAGES Most are Public Domain except theses Creative Commons with attributions: "Unstruttalbrücke" by Störfix From State Library of Queensland

×