Simplifying Mock Object Testing

From CitconWiki
Revision as of 21:40, 27 July 2007 by Jagraham (talk | contribs) (New page: Facilitated by Tom Adams == Overview == * Tom walked through setting up a unit test using mocks (using JMock 1). * He demonstrated how hard it can be to read even the most simple interact...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Facilitated by Tom Adams

Overview

  • Tom walked through setting up a unit test using mocks (using JMock 1).
  • He demonstrated how hard it can be to read even the most simple interactions due to the amount of scaffolding required
  • The group contributed to DRYing up the scaffolding
  • A superclass for mock object testing was created to house the simplified scaffolding
  • The unit tests became so simple that they appeared to simply be duplicating production code

Tools people mentioned

  • JMock 1
  • JMock2 wraps “mock” and “controller” in one
    • Side effect: need to have some way of explicitly moving from expectation-setting mode and replay mode. JMock2 is closer to the EasyMock style of explicit value seeding and method replay.
  • EasyMock
  • RMock
  • PicoUnit

Summary / comments

  • DRY up your mock setup
  • Create methods that express intent, e.g. Stack stack = makeMock(Stack.class);
  • Put these methods into an abstract testing class (e.g. MockObjecTestCase) for reuse
  • Use annotations to further reduce scaffolding and make roles more explicit (auto mocking)
  • At some point, the behavioural tests mirror production code and perhaps for non-state-based testing at some point the value is reduced