The Great Rhino Mocks
What is Rhino Mocks?
Rhino Mocks allows you to easily create mock objects and setup a wide range of expectations on them using strongly typed notation instead of compiler-opaque strings. It's as simple as:
IProjectView projectView = mocks.StrictMock();
Expect.Call(projectView.Title).Return("Project's Title");
Definitions:
Mock Object - an object that pretends to be another object and allows you to set expectations on its interactions with another object.
Interaction Based Testing - you specify a certain sequence of interactions between objects, initiate an action, and then verify that the sequence of interactions happened as you specified it.
State Based Testing - you initiate an action and then check for the expected results (return value, property, created object, etc).
Expectation - general name for validation that a particular method call is the expected one.
Record & Replay model - a model that allows for recording actions on a mock object and then replaying and verifying them. All mocking frameworks uses this model. Some (NMock, TypeMock.Net, NMock2) use it implicitly and some (EasyMock.Net, Rhino Mocks) use it explicitly.
Ordering - The ability to specify that replaying a sequence of method calls will occur in a specific order (or disorder).
What are its Capabilities:
1. Mock interfaces, delegates and classes, including those with parameterized constructors.
2. Set expectations on the called methods by using strongly typed mocks instead of strings.
3. Lends itself easily to refactoring & leaning on the compiler.
4. Allows a wide range of expectations to be set on a mock object or several mock objects.
5. Attention: Rhino Mocks can only mock interfaces, delegates and virtual methods of classes! (Although it is possible to get work around existing code and easily apply Rhino Mocks, see Example of testing an abstract class)
6. Rhino Mocks now supports "Recursive mocking" (as of revision 1683). Special guidance should be followed when using this functionality, however.
Rhino Mocks currently support the creation of the following types of mock objects.
Mock Objects - Strict replay semantics. Created by calling StrictMock()
Dynamic Mock - Loose replay semantics. Created by calling DynamicMock()
Partial Mock - Mock only requested methods. Created by calling PartialMock()
What is the meaning of these?
Strict replay semantics: Only the methods that were explicitly recorded are accepted as valid. This means that any call that is not expected would cause an exception and fail the test. All the expected methods must be called if the object is to pass verification.
Loose replay semantics: All method calls during the replay state are accepted. If there is no special handling setup for a given method, a null or zero is returned. All of the expected methods must be called for the object to pass verification.
Mocking only requested methods: This is available for classes only. It basically means that any non abstract method call will use the original method (no mocking) instead of relying on Rhino Mocks' expectations. You can selectively decide which methods should be mocked.
n unexpected call is ignored when you are using a dynamic mock. However, this is the only difference between the two types, in all other ways they are identical (ordering, recording a method expectation, callbacks, etc). Any expectations that were created during the record phase must be satisfied if the dynamic mock is to pass verification.
Dynamic mocks are useful when you want to check a small piece of functionality and you don't care about whatever else may happen to the object. Mock objects (StrictMock) are useful when you want complete control over what happens to the mocked object.
Partial mocks are useful when you want to mock a part of a class. This allows you to test abstract methods in isolation, for instance.
Stub
Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what’s programmed in for the test. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it ’sent’, or maybe only how many messages it ’sent’.
You can use mocks as stubs, you can create a dynamic mock and call PropertyBehavior on its methods. The problem is that this is really annoying. Here is the type of code that you have to write for even mildy complex stub.
Rhino Mocks allows you to easily create mock objects and setup a wide range of expectations on them using strongly typed notation instead of compiler-opaque strings. It's as simple as:
IProjectView projectView = mocks.StrictMock
Expect.Call(projectView.Title).Return("Project's Title");
Definitions:
Mock Object - an object that pretends to be another object and allows you to set expectations on its interactions with another object.
Interaction Based Testing - you specify a certain sequence of interactions between objects, initiate an action, and then verify that the sequence of interactions happened as you specified it.
State Based Testing - you initiate an action and then check for the expected results (return value, property, created object, etc).
Expectation - general name for validation that a particular method call is the expected one.
Record & Replay model - a model that allows for recording actions on a mock object and then replaying and verifying them. All mocking frameworks uses this model. Some (NMock, TypeMock.Net, NMock2) use it implicitly and some (EasyMock.Net, Rhino Mocks) use it explicitly.
Ordering - The ability to specify that replaying a sequence of method calls will occur in a specific order (or disorder).
What are its Capabilities:
1. Mock interfaces, delegates and classes, including those with parameterized constructors.
2. Set expectations on the called methods by using strongly typed mocks instead of strings.
3. Lends itself easily to refactoring & leaning on the compiler.
4. Allows a wide range of expectations to be set on a mock object or several mock objects.
5. Attention: Rhino Mocks can only mock interfaces, delegates and virtual methods of classes! (Although it is possible to get work around existing code and easily apply Rhino Mocks, see Example of testing an abstract class)
6. Rhino Mocks now supports "Recursive mocking" (as of revision 1683). Special guidance should be followed when using this functionality, however.
Rhino Mocks currently support the creation of the following types of mock objects.
Mock Objects - Strict replay semantics. Created by calling StrictMock()
Dynamic Mock - Loose replay semantics. Created by calling DynamicMock()
Partial Mock - Mock only requested methods. Created by calling PartialMock()
What is the meaning of these?
Strict replay semantics: Only the methods that were explicitly recorded are accepted as valid. This means that any call that is not expected would cause an exception and fail the test. All the expected methods must be called if the object is to pass verification.
Loose replay semantics: All method calls during the replay state are accepted. If there is no special handling setup for a given method, a null or zero is returned. All of the expected methods must be called for the object to pass verification.
Mocking only requested methods: This is available for classes only. It basically means that any non abstract method call will use the original method (no mocking) instead of relying on Rhino Mocks' expectations. You can selectively decide which methods should be mocked.
n unexpected call is ignored when you are using a dynamic mock. However, this is the only difference between the two types, in all other ways they are identical (ordering, recording a method expectation, callbacks, etc). Any expectations that were created during the record phase must be satisfied if the dynamic mock is to pass verification.
Dynamic mocks are useful when you want to check a small piece of functionality and you don't care about whatever else may happen to the object. Mock objects (StrictMock) are useful when you want complete control over what happens to the mocked object.
Partial mocks are useful when you want to mock a part of a class. This allows you to test abstract methods in isolation, for instance.
Stub
Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what’s programmed in for the test. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it ’sent’, or maybe only how many messages it ’sent’.
You can use mocks as stubs, you can create a dynamic mock and call PropertyBehavior on its methods. The problem is that this is really annoying. Here is the type of code that you have to write for even mildy complex stub.
Comments
Good work pranthaaaa
Sijith