In Testing: What are Mock objects and why do we need them?
When implementing unit test you might
encounter a common problem: the object you want to unit-test can only exist in
conjunction with other objects, and to build these objects (a.k.a.
dependencies) you might need to go through a different algorithm that is
outside of your scope. If you decide to go ahead and create these dependencies
in the standard manner your unit test might turn gradually into an “integration
test”. Mock objects provide a workaround
for such cases by making unit test maintainable and readable. The power of mock
objects is that you have a reflection of the methods that mocked objects
receive, so for example you can write testing code that verifies that a method
on one object is only called after a method on another object has been called.
What is Rhino Mocks
Rhino Mocks helps you create stubs for
objects in your code that you can use to simulate various situations. This is
useful for skipping a long process that will result in creating a full instance
of the object you want to mock.
Rhino Mocks belongs to a family of APIs
called “Mock Object Frameworks”. Similar
APIs include: NMock, EasyMock.NET, TypeMock Isolator, Moq, NSubstitute, JustMock,
FakeItEasy, Microsoft Fakes (formerly Moles, included with VS 2012 Ultimate)
RhinoMocks concepts
The following concepts are the building
blocks behind RhinoMocks:
Mock Object
An object that pretends to be another
object and allows you to set expectations on its
interactions with another object.
interactions with another object.
Difference between Mock object & Stub
The main difference is that a mock is an
object you can set expectations on. You can still setup expectations on the
stub object, but those expectations will never be verified. So a mock is a more
involved type of stubs where you have a mechanism to ensure a certain sequence
of function calls happened. For example, i.e. the mock framework provides you
with a monitor on the messages (methods) that the mocked object receives. If
you just want to pass a value to make you code act in a certain way, you can
use a stub. Both types of objects are provided by the RhinoMocks framework as
you can see in the examples below.
State-based testing (a.k.a. AAA model – Arrange, Act, Assert)
Initiate an action and then check that the
expected results (return value, property, created object, etc…) are maintained.
More on this in the “RhinoMocks AAA
model” section below.
Expectation
Validation that a particular method call is
the expected step.
Ordering
The API should be able to specify that
replaying a sequence of method calls will happen in a specific order
Record & Replay model: (a.k.a Interaction-based testing)
In the testing model used for earlier
version of RhinoMocks. It basically says that there are two semantic units in
your test code: Record and Replay. This is illustrated in the RhinoMocks Basic
Usage section.
RhinoMocks Basic Usage
1. Create a mock repository
MockRepository mocks = new MockRepository();
|
This is the
mock objects factory. It is used to create mock objects
2. Instantiate a mock object using the repository
ISomeInterface robot = mocks.CreateMock<ISomeInterface>();
|
3. “Record” the methods you expect to be called on the mock object
// this method has a
return type, so wrap it with Expect.Call
Expect.Call(robot.SendCommand("Wake Up")).Return("Groan");
// this method has
void return type, so simply call it
robot.Poke();
// when no return type, any extra information about the
method call
// is provided immediately after via static methods on
LastCall
LastCall.On(robot).Repeat.Twice();
//Set the mock object to a "Replay" state
where, as called, it will replay the operations just recorded.
mocks.ReplayAll();
|
The first
line above tells the framework that the client code should invoke SendCommand(“Wake
Up”) on the mock object, which should return the string “Groan”, while the
second line tells the framework that the client code should invoke the method
Poke() on the mock object. The parameters we send to the Mock object and the
return values are part of the test.
4. Now that you have recorded the call sequence that should be
implemented inside the client method call, invoke this client method call and
verify that these interactions with the mock object take place. This is the
“Replay” part
theButler.GetRobotReady();
//Check that all calls were made to the mock object.
mocks.VerifyAll();
|
RhinoMocks AAA model
The AAA (Arrange, Act, Assert) is a new
syntax standardization that was released starting with Rhino Mocks 3.5. In this
test model you arrange the state, then execute the code given the state, and
then assert that the expected state change has happened.
Here is an example that illustrates AAA
from the official blog:
Let’s say this is the class that we want to test (i.e. the client code that interacts with the mock object)
Let’s say this is the class that we want to test (i.e. the client code that interacts with the mock object)
public class
LoginController
{
private
readonly IUserRepository repository;
private
readonly INotificationSender sender;
public
LoginController(IUserRepository repository, INotificationSender sender)
{
this.repository
= repository;
this.sender
= sender;
}
public
void ForgotMyPassword(int
userId)
{
User user
= repository.GetUserById(userId);
sender.Send("Changed
password for " + user.Name);
}
}
|
Now this is the test for the method
ForgotMyPassword(), mocking the INotificationSender object:
public void
TestForgotMyPassword()
{
var userRepository =
MockRepository.GenerateStub<IUserRepository>();
var
notificationSender =
MockRepository.GenerateMock<INotificationSender>();
userRepository.Stub(x => x.GetUserById(5)).Return(new User
{ Id = 5, Name = "ayende" });
notificationSender.Expect(x
=> x.Send(null)).Constraints(Text.StartsWith("Changed"));
new
LoginController(userRepository, notificationSender).ForgotMyPassword(5);
notificationSender.VerifyAllExpectations();
}
|
Notice that for the other object we interact
with (IUserRepository), we only used the Stub() method for it and not a mock
methods like Expect(). This means we are not interested in monitoring what
calls are sent to it, we only care that this object would have the properties
specified in the stub we created in the test. While for the INotificationSender
object we need to make sure that the method Send() is invoked on it, with a
string that begins with “Changed”.
More is available about the difference
between the Expect() and Stub() methods here.
This is another test that uses a syntax
that is more readable (a lambda expression for the Send() method parameters):
public void
WhenUserForgetPasswordWillSendNotification_WithArgMatchingInTheLambda()
{
var
userRepository = MockRepository.GenerateStub<IUserRepository>();
var
notificationSender = MockRepository.GenerateStub<INotificationSender>();
userRepository.Stub(x => x.GetUserById(5)).Return(new User
{ Id = 5, Name = "ayende" });
new
LoginController(userRepository, notificationSender).ForgotMyPassword(5);
notificationSender.AssertWasCalled(x =>
x.Send(Arg<string>.Matches(s => s.StartsWith("Changed"))));
}
|
The syntax above explicitly states that
the call to Send() receives a string parameter that starts with “Changed”.
More tests can be found here.
What can be seen in the couple of tests above is that we set the state first
(the user with Id = 5), and then we do the action ForgotMyPassword() with Id 5;
and finally we Assert the methods that return a stub and send a notification
are called.
