There are two different schools of TDD: the "London School of TDD" ("Mockists") with proponents like Steve Freeman, Nat Pryce, J.B. Rainsberger leverage a top-down approach and heavy use of interfaces to craft roles of neighbour objects. They drive their design "outside-in" starting with end-to-end acceptance tests and focus on the interaction between objects. Testing them in isolation is achieved by heavy use of mocking.
On the contrary the "Chicago School of TDD" ("Classicists" like Kent Beck, Uncle Bob, ...) try to avoid mocks if possible. They prefere "state based testing" and focus on assertions on the return values.
References:
Blogpost "Mocks aren't Stubs", Martin Fowler: http://martinfowler.com/articles/mocksArentStubs.html
Paper "Mock Roles not objects", Freeman et al.: http://jmock.org/oopsla2004.pdf
Book "Growing Object Oriented Software guided by tests", Steve Freeman & Nat Pryce: http://www.growing-object-oriented-software.com/
17. Outside-In Design
UI
Domain Service
Repository DB Adapter
DB
Domain Service Interface
Unit Test
End2End Test
18. Outside-In Design
UI
Domain Service
Repository DB Adapter
DB
Repository Interface
Domain Service Interface
Unit Test
Unit Test
End2End Test
19. Outside-In Design
UI
Domain Service
Repository DB Adapter
DB
Repository Interface
Domain Service Interface
Unit Test
Unit Test
Integration
Test
End2End Test
20. Classicists Design
●Bottom-up
●emergent
●„TDD as if you meant it“ (YAGNI?)
●Middle ground?
●Acceptance tests => Domain
21. Classicist IO
out = pureFunction(in);
object.changeStateBasedOn(in);
out = object.getState();
●Functional
●State-based
33. TDD as if you meant it
1.Write exactly one failing test
2.Make the test pass by writing implementation code in the test method
3.When duplication is spotted extract the implementation from tests to:
1. a new method in the test class
2.an existing method in the test class
4.When more methods belong together extract them into a new class
5.Refactor as required
by Adi Bolboaca