Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Mockist vs. Classicists TDD

1,791 views

Published on

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/

Published in: Software
  • Danke - Bei der Session wäre ich gerne dabei gewesen!
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Mockist vs. Classicists TDD

  1. 1. Mockist vs. Classicist TDD Softwerkskammer Regionalgruppentreffen München 30.10.2014 David Völkel
  2. 2. Agenda ●Theory ●Pizza ●Kata
  3. 3. Classicists vs. Mockists ●Who knows?
  4. 4. Classicists vs. Mockists ●Who knows? ●Who leverages what?
  5. 5. Mockists?
  6. 6. Classicists?
  7. 7. How i stumbled upon… ●#GOOS ●#IsTDDDead ●Outside-In  ●Mocking  ●=> How work Classicist?
  8. 8. Classicists ●„old school“: Kent Beck, Uncle Bob, … ●state verification ●bottom-up/inside-out ●Avoid mocks when possible
  9. 9. Mockists ●„London School“: Steve Freeman, Nat Pryce ●XP 2000 „Endo-Testing: Unit Testing with Mock Objects “ ●OOPSLA 2004 „Mock Roles, not Objects“ ●Book „Growing Object Oriented Software“ #GOOS 2009
  10. 10. Mockists ●ATDD ●Outside-In Design ●Hexagonal / Ports&Adapters Architecture ●also for classicists ●Mocking to isolate layers ●Interaction based testing ●„Back-door“
  11. 11. Architecture ●Mockist OO-style ●Message Passing/Event-Architecture ●Topology / Message flow ●„Tell don‘t ask“ ●Classicist FP-style ●mutable objects encapsulating state ●pure functions & immutable value objects ●details: algorithms, logic, conditionals
  12. 12. Layer UI Domain Data Access DB
  13. 13. Domain Hexagonal / Ports & Adapters UI Domain Service Repository DB Adapter DB Repository Interface
  14. 14. Hexagonal / Ports & Adapters Domain Service Repository DB Mock DB Repository Interface Unit Test
  15. 15. ATDD From Growing Object-Oriented Software by Nat Pryce and Steve Freeman
  16. 16. Outside-In Design UI Domain Service Repository DB Adapter DB End2End Test
  17. 17. Outside-In Design UI Domain Service Repository DB Adapter DB Domain Service Interface Unit Test End2End Test
  18. 18. Outside-In Design UI Domain Service Repository DB Adapter DB Repository Interface Domain Service Interface Unit Test Unit Test End2End Test
  19. 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. 20. Classicists Design ●Bottom-up ●emergent ●„TDD as if you meant it“ (YAGNI?) ●Middle ground? ●Acceptance tests => Domain
  21. 21. Classicist IO out = pureFunction(in); object.changeStateBasedOn(in); out = object.getState(); ●Functional ●State-based
  22. 22. Mockist IO: CQS public Object myQuery() { return neighbour.query(); } when(neighbour.query()).thenReturn(in); ●Queries: Stubbing indirect input
  23. 23. Mockist IO: CQS public Object myQuery() { return neighbour.query(); } when(neighbour.query()).thenReturn(in); private void myCommand() { neighbour.command(out); } verify(neighbour).command(out); ●Queries: Stubbing indirect input ●Commands: Spies check indirect output
  24. 24. Let‘s code! ●Content: Kata „Game of Life“ ●Phase 1: Outside-In Mockist style ●Mockless Classicist design ●Phase 2: refactor to mockless Classicist design ●Mode: Mob Programming ●1 Driver ●N Navigators ●Variant: David = PO & facilitator
  25. 25. Outside-In Mockist style
  26. 26. Classicist Isolation ●No isolation = „front door“ ●Leaf ●Integrated test ●By design ●Context independence: parameterize methods/constructors, values/value objects, intermediary results ●„Functional Core, Imperative Shell“
  27. 27. String renderMail(String mail) { String name = userRepo.nameFor(mail); return renderMailAndName(mail, name); } @Test public void renderMail() { when(userRepo.nameFor("customer@gmail.com")) .thenReturn("Joe Customer"); assertEquals("customer@gmail.com <Joe Customer>", mailService.renderMail("customer@gmail.com")); } Isolation via mocks
  28. 28. String renderMail(String mail) { String name = userRepo.nameFor(mail); return renderMailAndName(mail, name); } @Test public void renderMail() { when(userRepo.nameFor("customer@gmail.com")) .thenReturn("Joe Customer"); assertEquals("customer@gmail.com <Joe Customer>", mailService.renderMail("customer@gmail.com")); } @Test public void renderMail() { assertEquals("customer@gmail.com <Joe Customer>", mailService.renderMailAndName("customer@gmail.com", "Joe Customer")); } Mockless isolation
  29. 29. Refactor mocks away
  30. 30. Retrospective
  31. 31. Bilder von RaminusFalcon http://commons.wikimedia.org/wiki/File:Split- scissors.svg?uselang=de
  32. 32. Lizenz Creative Commons Attribution-ShareAlike 3.0 https://creativecommons.org/licenses/by-sa/3.0/de/
  33. 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

×