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?

1. MOCKIST VS CLASSICIST
TDD
Softwerkskammer Hamburg
David Völkel
22.11.2016

2. @davidvoelkel
@softwerkskammer
@codecentric
TDD & Design

3. CLASSICIST
VS
MOCKIST?

4. MOCKISTS?

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. ● Problem
Zu viele integrierte Tests
=> Isoliert testen
● Mocks [& Interfaces]
● Behaviour Verification
● Outside-In Design
MOCKISTS

7. CLASSICISTS?

8. “Chicago“ oder “Detroit School“:
Kent Beck, Uncle Bob, Ron Jeffries,
…
CLASSICISTS

9. Weniger Mocks,
• nur an Prozessgrenze
• mehr Integrierte Tests
CLASSICISTS

10. Weniger Mocks,
• nur an Prozessgrenze
• mehr Integrierte Tests
Design
• bottom up vs emergent
CLASSICISTS

11. DESIGN
DIMENSIONEN
Unsicherheit
Richtung
Isolation

12. UNSICHERHEIT
Design Dimension

13. Akzeptanztest
DESIGN UNKLAR?

14. Akzeptanztest
DESIGN UNKLAR?

15. Akzeptanztest
DESIGN UNKLAR?

16. Akzeptanztest
1. Pass the Tests
2. Reveal Intention & No Duplication
3. Fewest Elements
4 RULES OF
SIMPLE DESIGN
"BeckDesignRules", Martin Fowler

17. Akzeptanztest
1. Pass the Tests
2. Reveal Intention & No Duplication
3. Fewest Elements
4 RULES OF
SIMPLE DESIGN

18. Akzeptanztest
EMERGENT DESIGN

19. Akzeptanztest
EMERGENT DESIGN

20. + Wenn Design unklar
+ Refaktorierbarkeit
EMERGENT DESIGN

21. + Wenn Design unklar
+ Refaktorierbarkeit
- Aufwändig
- Integrierte Tests
EMERGENT DESIGN

22. RICHTUNG
Design Dimension
Outside-In vs Inside-Out

23. GUI
Adapter
DRITTSERVICE FIX
3rd
Party
Service

24. Integrations
Test
Adapter
INSIDE-OUT
3rd
Party
Service

25. Test INSIDE-OUT
3rd
Party
Service

26. Test
GUI / Endpoint
OUTSIDE-IN

27. Unittest
Mock
OUTSIDE-IN
MOCKING

28. Test
OUTSIDE-IN
MOCKING

29. GUI / Endpoint
Akzeptanztest
OUTSIDE-IN
FAKE-IT

30. Fake
Akzeptanztest
OUTSIDE-IN
FAKE-IT

31. Fake
Akzeptanztest Fake
OUTSIDE-IN
FAKE-IT

32. Unittest
Akzeptanztest
OUTSIDE-IN
FAKE-IT

33. Akzeptanztest
OUTSIDE-IN
FAKE-IT

34. INSIDE-OUT
Sweetspots
Fixes Drittsystem
Design sehr klar
YAGNI Design Potential!

35. OUTSIDE-IN
Passgenaues Design
Mocks vs Fake It

36. ISOLATION
Design Dimension
Mocks vs Integrierte Tests

37. aufwendiges Setup
Fehlerfindung
# Testfällen
Langsames Feedback
Refactorability sinkt
Isolationsaufwand
Zu wenig Nutzen
Lesbarkeit
TRADE-OFF
ZU GROSS vs ZU KLEIN

38. OBSOLETES MOCKING

39. INTEGRATION OPERATION
SEGREGATION PRINCIPLE
"Integration Operation Segregation Principle", Ralf Westphal
"Die kniffligen Fälle beim Testen - Sichtbarkeit", Stefan Lieser

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. 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. 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. 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. 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. 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. PUSH LOGIC
DOWN THE STACK
Siehe "The Failures of “Intro to TDD”" - Justin Searls

47. PUSH LOGIC
DOWN THE STACK

48. MOCKING
SWEETSPOTS

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. SYSTEM GRENZEN
3rd
Party
Service
Adapter

51. SYSTEM GRENZEN
3rd
Party
Service
Mock

52. DESIGN
DIMENSIONEN
Unsicherheit
Richtung
Isolation

53. DESIGN
ALGORITHMUS
if (unsicher) Emergent
else if (drittsys) Inside-Out
else if (isoliert) Outside-In Mockist
else Outside-In Fake-It

54. DESIGN
ALGORITHMUS
if (unsicher) Emergent
else if (drittsys) Inside-Out
else if (isoliert) Outside-In Mockist
else Outside-In Fake-It

55. DESIGN
ALGORITHMUS
if (unsicher) Emergent
else if (drittsys) Inside-Out
else if (isoliert) Outside-In Mockist
else Outside-In Fake-It

56. DESIGN
ALGORITHMUS
if (unsicher) Emergent
else if (drittsys) Inside-Out
else if (isoliert) Outside-In Mockist
else Outside-In Fake-It

57. SCHULEN
if (unsicher) Emergent
else if (drittsys) Inside-Out
else if (isoliert) Outside-In MOCKIST
else Outside-In Fake-It
CLASSICIST

58. MOCKIST
ODER
CLASSICIST?

59. TRADE-OFF!

60. MOCKIST
ODER
CLASSICIST?
KOMBINIEREN!

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

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. Q&A ?!

64. Licence
Creative Commons
Attribution-ShareAlike 3.0