CSC/ECE 517 Fall 2009/wiki1a 2 i7

What are Mock Object Frameworks?

"Mock object frameworks" allow for the creation and use of "mock objects" which are used to mock existing roles in a system. Roles are identified in a system as an interface or abstract type where the responsibility of the object is made aware through its definition. Mock objects are typically provided behavior and expectations programatically to allow for testing interactions with them.

Where mock objects fit in:

Why use Mock Object Frameworks?

Using mock objects allows for testing interaction with an interface rather than an implementation. There are a variety of reasons this may be beneficial, some of which may be when the mocked object is:

• non-deterministic (i.e. time of day)
• able to exhibit behavior that is difficult to reproduce directly (i.e. time out exception)
• slow (i.e. accessing a database)

An example role in a system might be a DataProvider interface. Two implementation independent features of the getData() method of this interface may be that it returns a Data object and is able to throw a DataRetrievalException. An example definition is shown below in Java:

   interface DataProvider {
       Data getData() throws DataRetrievalException;
       boolean hasNext();
   }

A mock object in this case would be useful in a test which involves the interaction with a DataProvider, such as providing data to a DataConsumer class.

Example of a relationship between DataConsumers and DataProviders:

The implementation of the DataProvider is irrelevant to testing the correctness of a DataConsumer. The DataProvider interface provides a layer of abstraction to the DataConsumer, this clearly defines the contract that any implementation of a DataProvider must satisfy. Creating a barrier in this fashion and using a mock object allows for creating isolated unit tests in a complex system. The alternative would be setting up integration tests where an entire environment must be setup to test one particular component.

Mock DataProviders could be configured with behavior and expectations for each test case that the DataConsumer need be tested against. Some of the test cases may be when the DataProvider:

• returns a faulty Data object
• returns a legitimate Data object
• returns null
• throws a DataRetrievalException
• throws an unchecked exception

Typical Steps to using a Mock Object Framework

Create the mock object

This step involves creation of the mock object.

An example in Mockito:

   PositionProvider mockPositionProvider = mock(PositionProvider.class);

This declares a variable called mockPositionProvider which is a mock object of the PositionProvider class. This variable is initialized to have the value mock(PositionProvider.class). The mock method is a call to the Mockito framework which tells it to return a mock object of the PositionProvider class.

Define the stubbed methods

This step involves defining what methods should do when they are called. This step can be combined with the next step which is defining expectations.

An example in Flex Mock:

   mockPositionProvider.should_receive(:getX).times(1).and_return(10);

This uses chained method calls to declare that on the mockPositionProvider object the getX method should be called, the method should be called one time, and when called the method should return 10. An important feature to notice here is how natural using the mock object framework feels here, it should be noted that many mock object frameworks strive for this type of readability when designing their APIs. Reading from left to right you can easily understand what is going on, "the mockPositionProvider object should receive getX one time and return 10".

Define the expectations

This step involves defining what is expected to happen to the mock object when the test code is run such as what methods should be called, how many times should the methods be called, or what exceptions should be thrown.

An example in EasyMock:

   mockPositionProvider.getX()

This is plainly calling a method on a mocked object. In EasyMock, this is how expectations are created. Test code would be run at some point after this method call and then when the mock object is verified it will check if mockPositionProvider.getX() was indeed called through the test code.

Execution of the test code

This step involves invoking the code that is involved with interacting with the mocked object.

An example not specific to any Mock Object Framework:

   PositionProcessor processor = new PositionProcessor();
   processor.process(mockPositionProvider);

In this example we have a PositionProcessor class which processes PositionProviders. A case of code that is involved with interacting with the mocked object is when a PositionProvider is processed we might expect the getX() method to be called at least once.

Verify the expectations were satisfied

   Mockery context = new Mockery();
   // Create mock object.
   // Define the method stubs.
   // Define the expectations.
   // Execute the test code.
   context.assertIsSatisfied();

References

1. http://en.wikipedia.org/wiki/Mock_object

2. http://onjava.com/pub/a/onjava/2004/02/11/mocks.html#Approaches

3. http://msdn.microsoft.com/en-us/magazine/dd882516.aspx

4. http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html

External Links

• Java Mock Object Frameworks
  • Mockito
  • EasyMock
  • JMock
• Ruby Mock Object Frameworks
  • Mocha
  • Flex Mock