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.

1. TDD-Trade-Offs
Softwerkskammer Karlsruhe
David Völkel
09.04.2019

2. @davidvoelkel
@softwerkskammer
@codecentric
TDD & Design

3. 1.TDD-Trade-Offs
2."Outside-In Fake It TDD" Deep Dive
AGENDA

4. CLASSICIST
&
MOCKISTS?

5. MOCKISTS?

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

8. CLASSICISTS?

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

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

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

12. DESIGN
DIMENSIONEN
Unsicherheit
Isolation
Richtung
Komplexität

13. UNSICHERHEIT
Design Dimension

14. Akzeptanztest
DESIGN UNKLAR?

15. Akzeptanztest
DESIGN UNKLAR?

16. Akzeptanztest
DESIGN UNKLAR?

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

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

19. Akzeptanztest
EMERGENT DESIGN

20. Akzeptanztest
EMERGENT DESIGN

21. + Wenn Design unklar
+ Refaktorierbarkeit
EMERGENT DESIGN

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

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.
RICHTUNG
Design Dimension
Outside-In vs Bottom-Up / Inside-Out

25. GUI
Adapter
DRITTSERVICE
3rd
Party
Service

26. GUI
Adapter
DRITTSERVICE TREIBT
3rd
Party
Service

27. Integrations
Test
Adapter
3rd
Party
Service
BOTTOM UP

28. Test
3rd
Party
Service
BOTTOM UP

29. BOTTOM-UP
Sweet spots
Drittsystem treibt Design
Wenn Design sehr klar
YAGNI Design Potential!

30. ıINSIDE-OUT WENIG SINNVOLL
3rd
Party
Service
GUI
Domain-Service
Service-Client
Adapterlayer
("Outside")

31. Akzeptanz-Test
GUI / Endpoint
TOP-DOWN / "OUTSIDE-IN"

32. Unittest
Mock
OUTSIDE-IN
MOCKING

33. Test
OUTSIDE-IN
MOCKING

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

35. Fake
Akzeptanztest
OUTSIDE-IN
FAKE-IT

36. Fake
Akzeptanztest Fake
OUTSIDE-IN
FAKE-IT

37. Unittest
Akzeptanztest
OUTSIDE-IN
FAKE-IT

38. Akzeptanztest
OUTSIDE-IN
FAKE-IT

39.
OUTSIDE-IN
Passgenaues Design
Mocks vs Fake It

40.
ISOLATION
Design Dimension
Mocks vs Integrierte Tests

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

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

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. 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. 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. 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. 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. 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. 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. 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.
MOCKING
SWEETSPOTS

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

54. SYSTEM GRENZEN
3rd
Party
Service
Mock

55. KOMPLEXITÄÄAET
Design Dimension
Triangulation vs. Fake It

56. GREEN BAR PATTERNS*
Obvious Implementation
Fake it (until you make it)
Triangulation
* Kent Beck in "TDD by Example"

57. GREEN BAR PATTERNS
Obvious Implementation
Fake it
Triangulation
Trade-Off
Complexity

58. GREEN BAR PATTERNS
DEMO

59. SWEET SPOT
Trivial
GREEN BAR PATTERNS
Obvious Implementation
Fake it
Triangulation

60. SWEET SPOT
Trivial
Structure
GREEN BAR PATTERNS
Obvious Implementation
Fake it
Triangulation

61. SWEET SPOT
Trivial
Structure
Logic
GREEN BAR PATTERNS
Obvious Implementation
Fake it
Triangulation

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. ENTARTUNGEN
Kein TDD?
Keine Akzeptanztests?

64. if (unsicher) Emergent
else if (drittsys) Bottom-Up
else if (isoliert) Outside-In MOCKIST
else Outside-In Fake-It
CLASSICIST

65. MOCKIST
ODER
CLASSICIST?

67. MOCKIST
ODER
CLASSICIST?
KOMBINIEREN!

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

69. OUTSIDE-IN FAKE IT
DEEP DIVE

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. 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

72. PREPARATORY REFACTORINGS*
*"An example of preparatory refactoring", Martin Fowler

73. PREPARATORY REFACTORINGS*
*"An example of preparatory refactoring", Martin Fowler

74. "GREEN" PHASE TRIANGULATION
Implementation Run Test
"Green Phase"

75. LIMIT YOUR TIME IN RED
"Green Phase"
Implementation Run Test

76. LIMIT YOUR TIME IN RED
"Green Phase"
Implementation Run Test
Implementation Run TestPreparatory Refactoring

77. PREPARATORY REFACTORINGS
DEMO

78. CALCULATE
BACKWARDS
DEMO

79. DIAMOND KATA

80. FAKE IT OUTSIDE-IN
DEMO

81. DATA GUIDES STRUCTURE
Triangulation Fake It
Structure Cumbersome Data guides well

82. # BRANCHES
Triangulation Fake It
# N 1
More confidence
More effort

83. # BRANCHES
Triangulation Fake It
# N 1
Fake data easy to forget
Omitting cases is
tempting

84. TIME IN GREEN
Triangulation
Prep Refactoring
Triangulation
Fake It

85. WHY?
Outside-In
=> YAGNI free design
Without mocking drawbacks

86. WHY?
Outside-In
=> YAGNI free design
Without mocking drawbacks
Vs Triangulation
More time in GREEN
Better Design Guidance

87. 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

88. Q&A ?!

89. Licence
Creative Commons
Attribution-ShareAlike 3.0

90. IMAGES
Most are Public Domain except theses
Creative Commons with attributions:
"Unstruttalbrücke" by Störfix
From State Library of Queensland