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,607 views

Published on

The slides of my talk "Mockist vs. Classicists TDD" at the Softwerkskammer Berlin Meetup http://www.meetup.com/de-DE/Software-Craftsmanship-Berlin/events/227959647/.

Abstract:
There are two different schools of TDD: the proponents of "London School TDD" ("Mockists") drive their design "outside-in" top-down starting with end-to-end acceptance tests. They focus on the interaction between objects, isolate them with interfaces between them and mock them out in their tests. On the contrary the advocates of "Detroit School TDD" ("Classicists") work bottom-up and try to avoid mocks if possible.

In a live coding session I will demonstrate both approaches and discuss their strengths and weaknesses with you.

Published in: Software
  • Be the first to comment

  • Be the first to like this

Mockist vs. Classicists TDD

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

×