OO-Matron addresses problems I have encountered using Mock Objects in a test-driven development (TDD) process:

1. Tests with mock objects have a lot of set-up noise. It is hard to ignore interactions that are not salient to the behaviour being tested.
2. The simplest way to work around this is to move common stubs and expectations into the setUp() method. However, this has led to an unresolved (and unresolvable) issue in jMock that has led to much discussion among developers and users of the library. If you create stubs and expectations at set-up time, you want to override those in specific tests by specifying new ones. But in a test you want duplicate expectations to mean that the expected method calls should occur in the same order as the expectations are specified. There's no real right way to resolve these conflicting demands in the way that mock objects work.
3. This really highlights a deeper problem with mock objects — there is no easy way to factor out, group and name commonly used expectations and stubs.
4. Which is related to another drawback of mock objects:they cannot be turned into documentation. A unit test acts as a specification of the class being tested. Tools such as Testdox can turn test code into useful documentation of the class. Mock objects are used to design interfaces but cannot act as a specification of those interfaces. They only describe how each class being tested uses those interfaces.
5. And that is related to another drawback: mock objects cannot check consistency among different tests that define expectated calls to the same interface. Different tests can define inconsistent expectations. The inconsistency will only be detected by integration tests (if that early), which will require digging around with a debugger to solve. I want my unit tests to tell me "object a called b.m1 in this situation. A is only allowed to invoke b.m2 & c.m3 at this time."
6. Oh, and I don't like having to call .proxy() on my mock objects and I always forget to call it in my tests. I want to cast the mock object to the mocked type. It's easier to read and avoids obscure test failures.

OO-Matron solves all these problems. How? All will be revealed in the next programme. Until then you can check the code out of Subversion and have a look at the examples and acceptance tests.