This project is read-only.
Mockery was created after hours spent looking at old unit tests on constructor injected objects and observing the following qualities:
  1. There was a lot of redundant code in these unit tests in arranging and executing these tests.
  2. It was difficult to read the tests to understand what was being tested. Instead of comments and unit test naming conventions, the code should tell us simply and concisely.
  3. There were varying states of reliance on a shared Service Locator pattern inside of objects rather than relying on the IoC container to perform the object look ups. This further complicated the setup pattern on a test-by-test basis.

Mockery deals these issues on a couple of fronts. First, since setting up the RhinoMocks MockRepository itself on each test and managing its state was one source of code duplication, Mockery handles this process implicitly. You are indirectly provided access to the state of the MockRepository itself in setting up mocks/stubs while the AAA progress of test implicitly affects the MockRepository runtime state (Record/Replay/Verify).

Mockery addresses this issue by breaking the unit test out into 3 discrete areas:
  1. Arrange: The arrange method accepts a delegate using an 'Arrangement' object that allows you to build mocks, stubs and expectations with RhinoMocks.
  2. Act: The act method accepts a delegate using the Target object-under-test. You can perform multiple act methods in a Mockery instance, but typical unit tests will exercise one method/property per test. Act can be setup in a couple of ways
  3. Assert: The assert method allows you to test the state from the 'Act' method. The first 'Assert' method triggers a VerifyAll step in RhinoMocks to make sure that all expectation were met (if not, the data you are testing is questionable). Assert takes on 3 different forms

Finally, having the core components of a unit test in one location should permit the creation of a set of FxCop rules to help enforce good unit testing practices. For example, one mode of thought is that a unit test should have one mock where expectations are set and that other dependencies should be limited to stubs.

Last edited Jan 1, 2010 at 11:37 AM by sdhebert, version 3


No comments yet.