Embed Size (px)
Citation preview
Mockist vs. Classicist
TDD
Softwerkskammer Berlin
18.01.2016
David Völkel
@davidvoelkel
@softwerkskammer
TTD & Design
Agenda
● Talk ● Mockist
● Classicist
● Trade-offs
● Discussion
● Another Beer
Disclaimer
Classicists vs. Mockists
● Who knows?
Classicists vs. Mockists
● Who knows?
● Who leverages what?
Mockists?
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
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
“Double Loop“ ATDD
From Growing Object-Oriented
Software by Nat Pryce and Steve
Freeman
Outside-In Design
UI
Domain Service
Repository DB Adapter
DB
End2End Test
Outside-In Design
UI
Domain Service Mock
Repository DB Adapter
DB
Domain Service Interface
Unit Test
End2End Test
Outside-In Design
UI
Domain Service
Repository DB Adapter
DB
Repository Interface
Domain Service Interface
Unit Test
Unit Test
End2End Test
Outside-In Design
UI
Domain Service
Repository DB Adapter
DB
Repository Interface
Domain Service Interface
Unit Test
Unit Test
Integration
Test
End2End Test
Outside-In Design
UI
Domain Service
Repository DB Adapter
DB
Repository Interface
Domain Service Interface
Unit Test
Unit Test
Integration
Test
End2End Test
London School Demo
Double Loop ATTD
Outside-In Design
Classicists?
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)
Bottom-Up Design
Leaf Node Unit Test
Bottom-Up Design
Leaf Node
Leaf Node Unit Test
Unit Test
Bottom-Up Design
UI
Leaf Node
Leaf Node
Acceptance Test
Unit Test
Unit Test
Classicist Demo
“TDD as if you meant it“
Design Direction
Inside-Out
● Classicist default
● Design
unknown before
more emergent
Outside In
● Mockist default
● Classicist option
● YAGNI
● Design
clear before
Refactorability
Common objection:
"Mocking freezes the design and binds it to the
implementation"
Front-Door Classicist IO
out = pureFunction(in); object.changeStateBasedOn(in); out = object.getState();
● Functional
● State-based
Back-Door Mockist IO
public Object myQuery() { return repository.query(); } when(repository.query()).thenReturn(in);
● Queries: Stubbing indirect input
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
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
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
Criteria
● Design Uncertainty
● Complexity in non-leaf objects
● Architecture ● “Back-Door“ IO with external systems
● Message passing
Conclusion
Don`t be a Mockist
Don`t be a Classicist
Be both & choose the right tool for the right job
Questions & Discussion
Softwerkskammer Berlin
18.01.2016
David Völkel
Images
von RaminusFalcon
http://commons.wikimedia.org/wiki/File:Split-
scissors.svg?uselang=de
Lizenz
Creative Commons Attribution-ShareAlike 3.0
https://creativecommons.org/licenses/by-sa/3.0/de/
