Foundations of Programming - Karl Seguin

Chapter 5 - Unit Testing
you want to mock (an interface or a class – preferably an interface), tell it what method(s) you expect to
be called, along with the parameters, execute the call, and have it verify that your expectations were
met.
Before we can get started, we need to give RhinoMocks access to our internal types. This is quickly
achieved by adding [assembly: InternalsVisibleTo("DynamicProxyGenAssembly2")] to our
Properties/AssemblyInfo.cs file.
Now we can start coding by writing a test to cover the update path of our Save method:
[TestFixture]
public class CarTest
{
[Test]
public void SaveCarCallsUpdateWhenAlreadyExistingCar()
{
}
}
MockRepository mocks = new MockRepository();
IDataAccess dataAccess = mocks.CreateMock();
ObjectFactory.InjectStub(typeof(IDataAccess), dataAccess);
Car car = new Car();
dataAccess.Update(car);
mocks.ReplayAll();
car.Id = 32;
car.Save();
mocks.VerifyAll();
ObjectFactory.ResetDefaults();
Once a mock object is created, which took 1 line of code to do, we inject it into our dependency
injection framework (StructureMap in this case). When a mock is created, it enters record-mode, which
means any subsequent operations against it, such as the call to dataAccess.UpdateCar(car), is
recorded by RhinoMocks (nothing really happens since dataAcces is simply a mock object with no real
implementation). We exit record-mode by calling ReplayAll, which means we are now ready to
execute our real code and have it verified against the recorded sequence. When we then call
VerifyAll after having called Save on our Car object, RhinoMocks will make sure that our actual call
behaved the same as what we expected. In other words, you can think of everything before ReplayAll
as stating our expectations, everything after it as our actual test code with VerifyAll doing the final
check.
Foundations of Programming Copyright © Karl Seguin www.codebetter.com
39