Mockist vs Classicists TDD

153 Aufrufe

Veröffentlicht am

TDD ist nicht gleich TDD: die „London School of TDD“ mit Vertretern wie Steve Freeman und Nat Pryce stellt die Interaktionen der Objekte untereinander in den Fokus und ermöglicht durch starken Mocking-Einsatz, diese isoliert Unit-testen zu können. Mit dem zum Einsatz kommenden "Outside-In" Design erzielen die "Mockists" dabei zudem ein sehr passgenaues Design. Im Gegensatz dazu versucht die „Chicago School of TDD“ wenn irgendmöglich Mocks zu vermeiden. Diese sogenannten "Classicists" wie z.B. Kent Beck oder Uncle Bob setzen mehr auf „state based testing“ und verzichten mit integrierteren Tests zugunsten einer besseren Refaktorierbarkeit auf Isolation.

Was macht beide Ansätze aus und für welche Probleme eignen sich die jeweiligen Ansätze besser?

Veröffentlicht in: Software
0 Kommentare
1 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
153
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
2
Aktionen
Geteilt
0
Downloads
1
Kommentare
0
Gefällt mir
1
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Mockist vs Classicists TDD

  1. 1. MOCKIST VS CLASSICIST TDD Softwerkskammer Hamburg David Völkel 22.11.2016
  2. 2. @davidvoelkel @softwerkskammer @codecentric TDD & Design
  3. 3. CLASSICIST VS MOCKIST?
  4. 4. MOCKISTS?
  5. 5. ● „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
  6. 6. ● Problem Zu viele integrierte Tests => Isoliert testen ● Mocks [& Interfaces] ● Behaviour Verification ● Outside-In Design MOCKISTS
  7. 7. CLASSICISTS?
  8. 8. “Chicago“ oder “Detroit School“: Kent Beck, Uncle Bob, Ron Jeffries, … CLASSICISTS
  9. 9. Weniger Mocks, • nur an Prozessgrenze • mehr Integrierte Tests CLASSICISTS
  10. 10. Weniger Mocks, • nur an Prozessgrenze • mehr Integrierte Tests Design • bottom up vs emergent CLASSICISTS
  11. 11. DESIGN DIMENSIONEN Unsicherheit Richtung Isolation
  12. 12. UNSICHERHEIT Design Dimension
  13. 13. Akzeptanztest DESIGN UNKLAR?
  14. 14. Akzeptanztest DESIGN UNKLAR?
  15. 15. Akzeptanztest DESIGN UNKLAR?
  16. 16. Akzeptanztest 1. Pass the Tests 2. Reveal Intention & No Duplication 3. Fewest Elements 4 RULES OF SIMPLE DESIGN "BeckDesignRules", Martin Fowler
  17. 17. Akzeptanztest 1. Pass the Tests 2. Reveal Intention & No Duplication 3. Fewest Elements 4 RULES OF SIMPLE DESIGN
  18. 18. Akzeptanztest EMERGENT DESIGN
  19. 19. Akzeptanztest EMERGENT DESIGN
  20. 20. + Wenn Design unklar + Refaktorierbarkeit EMERGENT DESIGN
  21. 21. + Wenn Design unklar + Refaktorierbarkeit - Aufwändig - Integrierte Tests EMERGENT DESIGN
  22. 22. RICHTUNG Design Dimension Outside-In vs Inside-Out
  23. 23. GUI Adapter DRITTSERVICE FIX 3rd Party Service
  24. 24. Integrations Test Adapter INSIDE-OUT 3rd Party Service
  25. 25. Test INSIDE-OUT 3rd Party Service
  26. 26. Test GUI / Endpoint OUTSIDE-IN
  27. 27. Unittest Mock OUTSIDE-IN MOCKING
  28. 28. Test OUTSIDE-IN MOCKING
  29. 29. GUI / Endpoint Akzeptanztest OUTSIDE-IN FAKE-IT
  30. 30. Fake Akzeptanztest OUTSIDE-IN FAKE-IT
  31. 31. Fake Akzeptanztest Fake OUTSIDE-IN FAKE-IT
  32. 32. Unittest Akzeptanztest OUTSIDE-IN FAKE-IT
  33. 33. Akzeptanztest OUTSIDE-IN FAKE-IT
  34. 34. INSIDE-OUT Sweetspots Fixes Drittsystem Design sehr klar YAGNI Design Potential!
  35. 35. OUTSIDE-IN Passgenaues Design Mocks vs Fake It
  36. 36. ISOLATION Design Dimension Mocks vs Integrierte Tests
  37. 37. aufwendiges Setup Fehlerfindung # Testfällen Langsames Feedback Refactorability sinkt Isolationsaufwand Zu wenig Nutzen Lesbarkeit TRADE-OFF ZU GROSS vs ZU KLEIN
  38. 38. OBSOLETES MOCKING
  39. 39. INTEGRATION OPERATION SEGREGATION PRINCIPLE "Integration Operation Segregation Principle", Ralf Westphal "Die kniffligen Fälle beim Testen - Sichtbarkeit", Stefan Lieser
  40. 40. INTEGRATION OPERATION SEGREGATION PRINCIPLE public void sendMailingTo(String email) { Customer customer = customerDB.findCustomerBy(email); String title = customer.getSex() == Sex.MALE ? "Mr" : customer.getMaritialStatus() == MaritialStatus.MARRIED ? "Mrs" : "Ms"; String content = "Hello " + title + ". " + customer.getName() + ",nn" + "We have a special offer for you.nn" + "Best regards,n" + "ACME Customer Service"; mailService.sendMail(email, content); }
  41. 41. public void sendMailingTo(String email) { Customer customer = customerDB.findCustomerBy(email); String title = customer.getSex() == Sex.MALE ? "Mr" : customer.getMaritialStatus() == MaritialStatus.MARRIED ? "Mrs" : "Ms"; String content = "Hello " + title + ". " + customer.getName() + ",nn" + "We have a special offer for you.nn" + "Best regards,n" + "ACME Customer Service"; mailService.sendMail(email, content); } INTEGRATION OPERATION SEGREGATION PRINCIPLE
  42. 42. public void sendMailingTo(String email) { Customer customer = customerDB.findCustomerBy(email); String title = customer.getSex() == Sex.MALE ? "Mr" : customer.getMaritialStatus() == MaritialStatus.MARRIED ? "Mrs" : "Ms"; String content = "Hello " + title + ". " + customer.getName() + ",nn" + "We have a special offer for you.nn" + "Best regards,n" + "ACME Customer Service"; mailService.sendMail(email, content); } INTEGRATION OPERATION SEGREGATION PRINCIPLE
  43. 43. public void sendMailingTo(String email) { Customer customer = customerDB.findCustomerBy(email); String content = renderContent(customer); mailService.sendMail(email, content); } private String renderContent(Customer customer) { String title = customer.getSex() == Sex.MALE ? "Mr" : customer.getMaritialStatus() == MaritialStatus.MARRIED ? "Mrs" : "Ms"; return "Hello " + title + ". " + customer.getName() + ",nn" + "We have a special offer for you.nn" + "Best regards,n" + "ACME Customer Service"; } INTEGRATION OPERATION SEGREGATION PRINCIPLE
  44. 44. public void sendMailingTo(String email) { Customer customer = customerDB.findCustomerBy(email); String content = renderContent(customer); mailService.sendMail(email, content); } private String renderContent(Customer customer) { String title = customer.getSex() == Sex.MALE ? "Mr" : customer.getMaritialStatus() == MaritialStatus.MARRIED ? "Mrs" : "Ms"; return "Hello " + title + ". " + customer.getName() + ",nn" + "We have a special offer for you.nn" + "Best regards,n" + "ACME Customer Service"; } TESTS? N Unittests
  45. 45. public void sendMailingTo(String email) { Customer customer = customerDB.findCustomerBy(email); String content = renderContent(customer); mailService.sendMail(email, content); } private String renderContent(Customer customer) { String title = customer.getSex() == Sex.MALE ? "Mr" : customer.getMaritialStatus() == MaritialStatus.MARRIED ? "Mrs" : "Ms"; return "Hello " + title + ". " + customer.getName() + ",nn" + "We have a special offer for you.nn" + "Best regards,n" + "ACME Customer Service"; } TESTS? 1 Integrierter Test N Unittests
  46. 46. PUSH LOGIC DOWN THE STACK Siehe "The Failures of “Intro to TDD”" - Justin Searls
  47. 47. PUSH LOGIC DOWN THE STACK
  48. 48. MOCKING SWEETSPOTS
  49. 49. 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
  50. 50. SYSTEM GRENZEN 3rd Party Service Adapter
  51. 51. SYSTEM GRENZEN 3rd Party Service Mock
  52. 52. DESIGN DIMENSIONEN Unsicherheit Richtung Isolation
  53. 53. DESIGN ALGORITHMUS if (unsicher) Emergent else if (drittsys) Inside-Out else if (isoliert) Outside-In Mockist else Outside-In Fake-It
  54. 54. DESIGN ALGORITHMUS if (unsicher) Emergent else if (drittsys) Inside-Out else if (isoliert) Outside-In Mockist else Outside-In Fake-It
  55. 55. DESIGN ALGORITHMUS if (unsicher) Emergent else if (drittsys) Inside-Out else if (isoliert) Outside-In Mockist else Outside-In Fake-It
  56. 56. DESIGN ALGORITHMUS if (unsicher) Emergent else if (drittsys) Inside-Out else if (isoliert) Outside-In Mockist else Outside-In Fake-It
  57. 57. SCHULEN if (unsicher) Emergent else if (drittsys) Inside-Out else if (isoliert) Outside-In MOCKIST else Outside-In Fake-It CLASSICIST
  58. 58. MOCKIST ODER CLASSICIST?
  59. 59. TRADE-OFF!
  60. 60. MOCKIST ODER CLASSICIST? KOMBINIEREN!
  61. 61. MOCKIST ODER CLASSICIST? KOMBINIEREN! TRADE-OFFS!
  62. 62. 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 • "The Failures of “Intro to TDD”" Justin Searls
  63. 63. Q&A ?!
  64. 64. Licence Creative Commons Attribution-ShareAlike 3.0

×