CSC/ECE 517 Fall 2009/wiki1a 2 i7: Difference between revisions
No edit summary |
No edit summary |
||
Line 19: | Line 19: | ||
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. | 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. | ||
[[Image:Mockdataprovider.png]] | [[Image:Mockdataprovider.png]] | ||
Revision as of 18:26, 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.
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 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
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