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
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
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)
Design Direction
Inside-Out
● Classicist default
● Design
unknown before
more emergent
Outside In
● Mockist default
● Classicist option
● YAGNI
● Design
clear before
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