The Code Wiki

Mocking

To get started, it’s a good idea to test simple pieces of functionality. Before long though, you’ll want to test a method that has a dependency on an outside component – such as the database. For example, you might want to complete your test coverage of the Car class by testing the Save method. Since we want to keep our tests as granular as possible (and as light as possible – tests should be quick to run so we can execute them often and get instant feedback) we really don’t want to figure out how we’ll set up a test database with fake data and make sure it’s kept in a predictable state from test to test. In keeping with this spirit, all we want to do is make sure that Save interacts property with the DAL. Later on we can unit test the DAL on its own. If Save works as expected and the DAL works as expected and they interact properly with each other, we have a good base to move to more traditional testing.

In the previous chapter we saw the beginnings of testing with mocks. We were using a manually created mock class which had some pretty major limitations. The most significant of which was our inability to confirm that calls to our mock objects were occurring as expected. That, along with ease of use, is exactly the problem RhinoMock is meant to solve. Using RhinoMocks couldn’t be simpler, tell it what 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.

We can test all of this by forcing our test to fail (notice the extra dataAccess.Update call):

[Test]

public void SaveCarCallsUpdateWhenAlreadyExistingCar()

{

MockRepository mocks = new MockRepository();

IDataAccess dataAccess = mocks.CreateMock();

ObjectFactory.InjectStub(typeof(IDataAccess), dataAccess);

Car car = new Car();

dataAccess.Update(car);

dataAccess.Update(car);

mocks.ReplayAll();

car.Id = 32;

car.Save();

mocks.VerifyAll();

ObjectFactory.ResetDefaults();

}

Our test will fail with a message from RhinoMocks saying two calls to Update were expected, but only one actually occurred.

For the Save behavior, the interaction is slightly more complex – we have to make sure the return value is properly handled by the Save method. Here’s the test:

[Test]

public void SaveCarCallsSaveWhenNew()

{

MockRepository mocks = new MockRepository();

IDataAccess dataAccess = mocks.CreateMock();

ObjectFactory.InjectStub(typeof(IDataAccess), dataAccess);

Car car = new Car();

Expect.Call(dataAccess.Save(car)).Return(389);

mocks.ReplayAll();

car.Save();

mocks.VerifyAll();

Assert.AreEqual(389, car.Id);

ObjectFactory.ResetDefaults();

}

Using the Expect.Call method allows us to specify the return value we want. Also notice the Assert.Equal we’ve added – which is the last step in validating the interaction. Hopefully the possibilities of having control over return values (as well as output/ref values) lets you see how easy it is to test for edge cases.

If we changed our Save function to throw an exception if the returned id was invalid, our test would look like:

[TestFixture]

public class CarTest

{

private MockRepository _mocks;

private IDataAccess _dataAccess;

[SetUp]

public void SetUp()

{

_mocks = new MockRepository();

_dataAccess = _mocks.CreateMock();

ObjectFactory.InjectStub(typeof(IDataAccess), _dataAccess);

}

[TearDown]

public void TearDown()

{

_mocks.VerifyAll();

}

[Test, ExpectedException("CodeBetter.Foundations.PersistenceException")]

public void SaveCarCallsSaveWhenNew()

{

Car car = new Car();

Expect.Call(_dataAccess.Save(car)).Return(0);

_mocks.ReplayAll();

car.Save();

}

}

In addition to showing how you can test for an exception (via the ExpectedException attribute), we’ve also extracted the repetitive code that creates, sets up and verifies the mock object into the SetUp and TearDown methods.