Upgrade to Pro — share decks privately, control downloads, hide ads and more …

reality is expensive: a better way of thinking ...

Justin Searls
November 10, 2012

reality is expensive: a better way of thinking about mock objects

Videos of this talk:
Rocky Mountain Ruby '12 — http://www.youtube.com/watch?v=TU3glG08BJI
Øredev 2012 — http://vimeo.com/53276460
SCNA 2012 — http://vimeo.com/54045166

This talk is an introduction to the different ways people use test doubles (be they mocks, fakes, stubs, or spies). Our goal will be to establish a more sophisticated means of communicating on the topic. This talk discusses our need to understand that reality is a variable under our control, the pros & cons of the different testing strategies, and the smells of test double abuse.

Justin Searls

November 10, 2012
Tweet

More Decks by Justin Searls

Other Decks in Programming

Transcript

  1. selenium A user who moves the mouse & keyboard exactly

    how you tell it to. Over and over.
  2. selenium A user who moves the mouse & keyboard exactly

    how you tell it to. Over and over. Every time.
  3. test data Runner cleans the database on every test run.

    Got years of data migrations? No problem!
  4. mock The popular term for a fake object that takes

    the place of a real object when a test is executed. n. \ˈmäk, ˈmȯk\
  5. test double The precise term for a fake object that

    takes the place of a real object when a test is executed. n. \ˈtest də-bəl\
  6. ensures certain messages are received (and explodes upon receiving any

    unexpected messages) fake test double stub mock
  7. value cost prove it works • confidence that passing equals

    working • fewer tests → less effort spent writing tests
  8. value cost prove it works • confidence that passing equals

    working • fewer tests → less effort spent writing tests • tests can't provide many design cues
  9. value cost prove it works • confidence that passing equals

    working • fewer tests → less effort spent writing tests • tests can't provide many design cues • slow feedback
  10. value cost prove it works • confidence that passing equals

    working • fewer tests → less effort spent writing tests • tests can't provide many design cues • slow feedback • high coverage is infeasible
  11. value cost mocking boundaries • each object is exercised by

    many tests • practical tests without deep knowledge of test doubles
  12. value cost mocking boundaries • each object is exercised by

    many tests • practical tests without deep knowledge of test doubles • tests give less feedback about interactions
  13. value cost mocking boundaries • each object is exercised by

    many tests • practical tests without deep knowledge of test doubles • tests give less feedback about interactions • one change → many test fixes
  14. value cost mocking boundaries • each object is exercised by

    many tests • practical tests without deep knowledge of test doubles • tests give less feedback about interactions • one change → many test fixes • end-to-end is extra redundant
  15. value cost case-by-case • developers free to choose best approach

    • your team is likely already doing it! • test doubles easily abused
  16. value cost case-by-case • developers free to choose best approach

    • your team is likely already doing it! • test doubles easily abused • no strategy → murky test value
  17. value cost case-by-case • developers free to choose best approach

    • your team is likely already doing it! • test doubles easily abused • no strategy → murky test value • "wanna mock that?" timesink
  18. value cost the GOOS way • TDD gives rich feedback

    about interactions • consistent, fast, complete
  19. value cost the GOOS way • TDD gives rich feedback

    about interactions • consistent, fast, complete • easy to extract from app to libs
  20. value cost the GOOS way • TDD gives rich feedback

    about interactions • consistent, fast, complete • easy to extract from app to libs • requires discipline & practice
  21. value cost the GOOS way • TDD gives rich feedback

    about interactions • consistent, fast, complete • easy to extract from app to libs • requires discipline & practice • awkward "in- between" tests
  22. value cost the GOOS way • TDD gives rich feedback

    about interactions • consistent, fast, complete • easy to extract from app to libs • requires discipline & practice • awkward "in- between" tests • frameworks dislike isolation
  23. 1. agree on literally any clear strategy 2. follow that

    strategy consistently my favorite strategy