CSC/ECE 517 Fall 2009/wiki1a 2 i7: Difference between revisions
Line 23: | Line 23: | ||
Example of a relationship between DataConsumers and DataProviders: | '''Example of a relationship between DataConsumers and DataProviders:''' | ||
[[Image:Mockdataprovider.png]] | [[Image:Mockdataprovider.png]] |
Revision as of 18:55, 7 September 2009
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.
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:
Role mockRole = mock(Role.class);
This declares a variable called Role which is a mock object of the Role class. This variable is initialized to have the value mock(Role.class). The mock method is a call to the Mockito framework which tells it to return a mock object of the Role 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:
mockRole.should_receive(:getInt).times(3). and_return(10, 12, 14)
One of the first things 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. Reading from left to right you can easily understand what is going on, "the mockRole object should receive getInt three times and return 10, 12, and 14".
Define the expectations
Execution of the test code
Verify the expectations were satisfied
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