MOCKIST VS CLASSICIST
TDD
Softwerkskammer Hamburg
David Völkel
22.11.2016
@davidvoelkel
@softwerkskammer
@codecentric
TDD & Design
CLASSICIST
VS
MOCKIST?
MOCKISTS?
● „London School“:
Steve Freeman, Nat Pryce
● XP 2000 paper
„Endo-Testing:
Unit Testing with Mock Objects “
● OOPSLA 2004
...
● Problem
Zu viele integrierte Tests
=> Isoliert testen
● Mocks [& Interfaces]
● Behaviour Verification
● Outside-In Desig...
CLASSICISTS?
“Chicago“ oder “Detroit School“:
Kent Beck, Uncle Bob, Ron Jeffries,
…
CLASSICISTS
Weniger Mocks,
• nur an Prozessgrenze
• mehr Integrierte Tests
CLASSICISTS
Weniger Mocks,
• nur an Prozessgrenze
• mehr Integrierte Tests
Design
• bottom up vs emergent
CLASSICISTS
DESIGN
DIMENSIONEN
Unsicherheit
Richtung
Isolation
UNSICHERHEIT
Design Dimension
Akzeptanztest
DESIGN UNKLAR?
Akzeptanztest
DESIGN UNKLAR?
Akzeptanztest
DESIGN UNKLAR?
Akzeptanztest
1. Pass the Tests
2. Reveal Intention & No Duplication
3. Fewest Elements
4 RULES OF
SIMPLE DESIGN
"BeckDesi...
Akzeptanztest
1. Pass the Tests
2. Reveal Intention & No Duplication
3. Fewest Elements
4 RULES OF
SIMPLE DESIGN
Akzeptanztest
EMERGENT DESIGN
Akzeptanztest
EMERGENT DESIGN
+ Wenn Design unklar
+ Refaktorierbarkeit
EMERGENT DESIGN
+ Wenn Design unklar
+ Refaktorierbarkeit
- Aufwändig
- Integrierte Tests
EMERGENT DESIGN
RICHTUNG
Design Dimension
Outside-In vs Inside-Out
GUI
Adapter
DRITTSERVICE FIX
3rd
Party
Service
Integrations
Test
Adapter
INSIDE-OUT
3rd
Party
Service
Test INSIDE-OUT
3rd
Party
Service
Test
GUI / Endpoint
OUTSIDE-IN
Unittest
Mock
OUTSIDE-IN
MOCKING
Test
OUTSIDE-IN
MOCKING
GUI / Endpoint
Akzeptanztest
OUTSIDE-IN
FAKE-IT
Fake
Akzeptanztest
OUTSIDE-IN
FAKE-IT
Fake
Akzeptanztest Fake
OUTSIDE-IN
FAKE-IT
Unittest
Akzeptanztest
OUTSIDE-IN
FAKE-IT
Akzeptanztest
OUTSIDE-IN
FAKE-IT
INSIDE-OUT
Sweetspots
Fixes Drittsystem
Design sehr klar
YAGNI Design Potential!
OUTSIDE-IN
Passgenaues Design
Mocks vs Fake It
ISOLATION
Design Dimension
Mocks vs Integrierte Tests
aufwendiges Setup
Fehlerfindung
# Testfällen
Langsames Feedback
Refactorability sinkt
Isolationsaufwand
Zu wenig Nutzen
Le...
OBSOLETES MOCKING
INTEGRATION OPERATION
SEGREGATION PRINCIPLE
"Integration Operation Segregation Principle", Ralf Westphal
"Die kniffligen F...
INTEGRATION OPERATION
SEGREGATION PRINCIPLE
public void sendMailingTo(String email) {
Customer customer = customerDB.findC...
public void sendMailingTo(String email) {
Customer customer = customerDB.findCustomerBy(email);
String title = customer.ge...
public void sendMailingTo(String email) {
Customer customer = customerDB.findCustomerBy(email);
String title = customer.ge...
public void sendMailingTo(String email) {
Customer customer = customerDB.findCustomerBy(email);
String content = renderCon...
public void sendMailingTo(String email) {
Customer customer = customerDB.findCustomerBy(email);
String content = renderCon...
public void sendMailingTo(String email) {
Customer customer = customerDB.findCustomerBy(email);
String content = renderCon...
PUSH LOGIC
DOWN THE STACK
Siehe "The Failures of “Intro to TDD”" - Justin Searls
PUSH LOGIC
DOWN THE STACK
MOCKING
SWEETSPOTS
public String signup(String username) throws Exception {
if(userDB.findUserBy(username) == null) {
userDB.createUser(new U...
SYSTEM GRENZEN
3rd
Party
Service
Adapter
SYSTEM GRENZEN
3rd
Party
Service
Mock
DESIGN
DIMENSIONEN
Unsicherheit
Richtung
Isolation
DESIGN
ALGORITHMUS
if (unsicher) Emergent
else if (drittsys) Inside-Out
else if (isoliert) Outside-In Mockist
else Outside...
DESIGN
ALGORITHMUS
if (unsicher) Emergent
else if (drittsys) Inside-Out
else if (isoliert) Outside-In Mockist
else Outside...
DESIGN
ALGORITHMUS
if (unsicher) Emergent
else if (drittsys) Inside-Out
else if (isoliert) Outside-In Mockist
else Outside...
DESIGN
ALGORITHMUS
if (unsicher) Emergent
else if (drittsys) Inside-Out
else if (isoliert) Outside-In Mockist
else Outside...
SCHULEN
if (unsicher) Emergent
else if (drittsys) Inside-Out
else if (isoliert) Outside-In MOCKIST
else Outside-In Fake-It...
MOCKIST
ODER
CLASSICIST?
TRADE-OFF!
MOCKIST
ODER
CLASSICIST?
KOMBINIEREN!
MOCKIST
ODER
CLASSICIST?
KOMBINIEREN!
TRADE-OFFS!
QUELLEN
• "Growing Object Oriented Systems",
Nat Pryce, Steve Freeman
• "Mocks Aren't Stubs",
Martin Fowler
• "Integration...
Q&A ?!
Licence
Creative Commons
Attribution-ShareAlike 3.0
Nächste SlideShare
Wird geladen in …5
×

Mockist vs Classicists TDD

298 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
298
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
2
Aktionen
Geteilt
0
Downloads
4
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

×