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/