The slides of my talk "Mockist vs. Classicists TDD" at the Softwerkskammer Berlin Meetup http://www.meetup.com/de-DE/Software-Craftsmanship-Berlin/events/227959647/. Abstract: There are two different schools of TDD: the proponents of "London School TDD" ("Mockists") drive their design "outside-in" top-down starting with end-to-end acceptance tests. They focus on the interaction between objects, isolate them with interfaces between them and mock them out in their tests. On the contrary the advocates of "Detroit School TDD" ("Classicists") work bottom-up and try to avoid mocks if possible. In a live coding session I will demonstrate both approaches and discuss their strengths and weaknesses with you.

1. Mockist vs. Classicist
TDD
Softwerkskammer Berlin
18.01.2016
David Völkel

2. @davidvoelkel
@softwerkskammer
TTD & Design

3. Agenda
● Talk
● Mockist
● Classicist
● Trade-offs
● Discussion
● Another Beer

4. Disclaimer

5. Classicists vs. Mockists
● Who knows?

6. Classicists vs. Mockists
● Who knows?
● Who leverages what?

7. Mockists?

8. Mockists
● „London School“:
Steve Freeman, Nat Pryce
J.B. Rainsberger
● XP 2000 paper
„Endo-Testing: Unit Testing with Mock Objects “
● OOPSLA 2004 „Mock Roles, not Objects“
● Book „Growing Object Oriented Software“
#GOOS 2009

9. Mockists
● Problem
too many integrated tests
=> break dependencies to test in isolation
● Interfaces & Mocks
● behaviour verification on non-leaf objects,
“Back Door Testing“
● Outside-In Design

10. “Double Loop“ ATDD
From Growing Object-Oriented
Software by Nat Pryce and Steve
Freeman

11. Outside-In Design
UI
Domain Service
Repository DB Adapter
DB
End2End Test

12. Outside-In Design
UI
Domain Service Mock
Repository DB Adapter
DB
Domain Service Interface
Unit Test
End2End Test

13. Outside-In Design
UI
Domain Service
Repository DB Adapter
DB
Repository Interface
Domain Service Interface
Unit Test
Unit Test
End2End Test

14. Outside-In Design
UI
Domain Service
Repository DB Adapter
DB
Repository Interface
Domain Service Interface
Unit Test
Unit Test
Integration
Test
End2End Test

15. Outside-In Design
UI
Domain Service
Repository DB Adapter
DB
Repository Interface
Domain Service Interface
Unit Test
Unit Test
Integration
Test
End2End Test

16. London School Demo
Double Loop ATTD
Outside-In Design

17. Classicists?

18. Classicists
● “Detroit School“: Kent Beck, Uncle Bob, …
more integrated testing
● “front door testing“ & “state verification“
● Only mock at the process boundary
● 3rd Party Systems
● Own DB?
● Design emerges bottom-up/inside-out
(mostly)

19. Bottom-Up Design
Leaf Node Unit Test

20. Bottom-Up Design
Leaf Node
Leaf Node Unit Test
Unit Test

21. Bottom-Up Design
UI
Leaf Node
Leaf Node
Acceptance Test
Unit Test
Unit Test

22. Classicist Demo
“TDD as if you meant it“

23. Design Direction
Inside-Out
● Classicist default
● Design
unknown before
more emergent
Outside In
● Mockist default
● Classicist option
● YAGNI
● Design
clear before

24. Refactorability
Common objection:
"Mocking freezes the design and binds it to the
implementation"

25. Front-Door Classicist IO
out = pureFunction(in);
object.changeStateBasedOn(in);
out = object.getState();
● Functional
● State-based

26. Back-Door Mockist IO
public Object myQuery() {
return repository.query();
}
when(repository.query()).thenReturn(in);
● Queries: Stubbing indirect input

27. Back-Door Mockist IO
public Object myQuery() {
return repository.query();
}
when(repository.query()).thenReturn(in);
private void myCommand() {
mailGateway.sendMail(out);
}
verify(mailGateway).sendMail(out);
● Queries: Stubbing indirect input
● Commands: Spies check indirect output

28. Mocking is awkward
when(neighbour.query()).thenReturn(in);
verify(neighbour).command(out);
Harder to read
● more verbose
● JMock expectations break AAA
● non-primitive types hard to verify

29. Classicist Isolation
● No isolation = „front door“
● Leaf
● Integrated test
● Separate IO & Logic
● “Functional Core, Imperative Shell“, Gary Bernhard
● “IODA Architecture“, Ralf Westphal
● “Intermediary Results“ , Kent Beck
● “Ultratestable Coding Style“, Jessica Kerr

30. Criteria
● Design Uncertainty
● Complexity in non-leaf objects
● Architecture
● “Back-Door“ IO with external systems
● Message passing

31. Conclusion
Don`t be a Mockist
Don`t be a Classicist
Be both & choose the right tool for the right job

32. Questions & Discussion
Softwerkskammer Berlin
18.01.2016
David Völkel

33. Images
von RaminusFalcon
http://commons.wikimedia.org/wiki/File:Split-
scissors.svg?uselang=de

34. Lizenz
Creative Commons Attribution-ShareAlike 3.0
https://creativecommons.org/licenses/by-sa/3.0/de/