Recent articles:
Popular archives:
Java: A platform for platforms
Sun's reorg may seem promising to shareholders but it's also a scramble for position. The question now is whether Sun can,
or wants to, maintain its hold on Java technology. Especially with enterprise leaders like SpringSource and RedHat investing
heavily in Java's future as a platform for platforms
Also see:
Discuss: Tim Bray on 'What Sun Should Do'
A good mock framework can make writing unit tests a breeze. A bad mock framework can deter even the most conscientious of developers. When writing the tests takes two or three times longer than writing the actual code itself, well, that's just too much work to do everyday. But in an enterprise or open source environment with dozens of constantly changing contributors and an evolving codebase, the importance of unit tests really can't be understated.
This article shows one approach towards simplifying the writing of mock objects. This approach combines the best features of the two types of mocks objects—dynamic and static. Using this technique, a developer can write useful mock objects within minutes.
Mock objects are used to isolate sections of code for testing. Let's say we wanted to test a translation-style object that takes input from a servlet, builds an object, and sends the object to some kind of persister. To test whether the translation is occurring properly, we would use a mock implementation of the persister, pretend to be the servlet, and pass some data into the translation object. The translator accepts the data, none the wiser that it's in a test environment, and passes the result to the mock persistence object. The mock would accept the object, which the test can then inspect and verify.
In the above scenario and in most other unit tests, mock objects allow us to examine and control the test environment. The mock object framework used determines what can be tested and how it can be tested. There are two general types of mock objects: static and dynamic. Static mock objects are prewritten. They usually inherit a common interface, though sometimes they extend the original class. Dynamic mock objects are generated on the fly, usually by some kind of proxy or bytecode manipulation. Static mock objects have the benefit of being specific to the codebase, but they can also be difficult to write. Dynamic mocks are easy to write, but often require much more setup than static mocks, as they offer only the most generic functionality.
Every mock object fulfills three roles. These roles are independent of each other and are as follows:
The first requirement can vary wildly depending on how we want to use the mock. The second and third requirements don't change much from mock to mock, which is why we can move the latter two roles into a dynamic framework. In practice, this means writing a static mock that deals only with returning data. We then pass this static mock object through a dynamic system that automatically records function calls and throws predefined exceptions. This allows us to create a full-featured mock object with very little effort.
Archived Discussions (Read only)