Mock Objects is a Technique, Not a Technology

George Malamidis recently proposed an alternative to mock objects in Groovy. Instead of using mock objects you can just use Groovy's Expando class to make an object that behaves like another type and checks that it is being invoked as expected.

But... that is a mock object!

Mock objects are not a specific technology, such as jMock or EasyMock they are a technique for the test-driven development of object-oriented code that follows a Tell, Don't Ask design style.

You can write mock objects with a framework, by using the reflection and metaprogramming facilities of a dynamic language, by coding everything by hand, or by generating the code at compile time. Whatever floats your boat.

However, faking out the mocked type is only a small part of what a mock object framework like jMock does. In fact, of the 2487 lines of code that make up jMock 2 only 34 are required to perform what we whimsically call "imposterisation". The remainder provide syntactic sugar to ensure the test code clearly expresses the intent of the test, let the programmer precisely specify the expected interactions between objects and generate clear diagnostics when tests fail. This functionality is vital if tests are to be helpful during the ongoing development of the code.