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'

Featured Whitepapers
Newsletter sign-up
View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java
Email Address:

Hand-rolled mocks made easy

A hybrid approach to writing mock objects

  • Digg
  • Reddit
  • SlashDot
  • Stumble
  • del.icio.us
  • Technorati
  • dzone

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.

Background

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.

The concept

Every mock object fulfills three roles. These roles are independent of each other and are as follows:

  1. The mock must return a predefined value when the proper function is called
  2. The mock must allow the test to see which functions on the mock were called, the arguments passed in, the function return value, and sometimes the order of the calls
  3. The mock must throw a predefined exception if the test demands it

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.

  • Digg
  • Reddit
  • SlashDot
  • Stumble
  • del.icio.us
  • Technorati
  • dzone
Comment
Login
Forgot your account info?
Add comment
Anonymous comments subject to approval. Register here for member benefits.
Have a JavaWorld account? Log in here. Register now for a free account.
Resources