108

CHAPTER 5

Isolation (mock object) frameworks

//we expected "Filename too short:abc.ext" simulatedService.LogError("bad string");

}

LogAnalyzer log = new LogAnalyzer(simulatedService); string tooShortFileName="abc.ext"; log.Analyze(tooShortFileName);

mocks.VerifyAll();

}

Mocks created with an isolation framework can also be used as stubs. We can tell them to return simulated values and create other interesting effects. The next section shows how to do that.

5.4 Returning values from fake objects

To return values from fake objects, you’ll almost always want to create a stub, and not a mock object. That means you can use either the static

MockRepository.GenerateStub<T> method or the Stub<T> instance

method. You’ll see this in the next section.

You won’t often need to, but you can also return values using mock objects, so let’s look at how to do that. You can instruct the mock object to return a value based on a method call by using a special class

called LastCall.

Listing 5.5 shows how we can return a value from a mock object when the interface method has a nonvoid return value. For this example, we’ll add an IGetResults interface into the system. During the recording stage, we use the LastCall class to set the return value for that method call when that specific input (a, in this case) is sent to the method.

Listing 5.5 Returning a value from a mock object using the LastCall class

[Test]

public void ReturnResultsFromMock()

{

MockRepository mocks = new MockRepository();

IGetResults resultGetter = mocks.DynamicMock<IGetResults>();

Returning values from fake objects

109

using(mocks.Record())		?
{

resultGetter.GetSomeNumber("a");

LastCall.Return(1); Forces method call to return value

resultGetter.GetSomeNumber("a");

LastCall.Return(2);

resultGetter.GetSomeNumber("b");

LastCall.Return(3);

}

int result = resultGetter.GetSomeNumber("b"); Assert.AreEqual(3, result);

int result2 = resultGetter.GetSomeNumber("a"); Assert.AreEqual(1, result2);

int result3 = resultGetter.GetSomeNumber("a"); Assert.AreEqual(2, result3);

}

As you can see in listing 5.5, there are three expectations set on the mock object, and after each one we set the result to be returned from these method calls. Our mock object will be smart enough to return the correct value based on the input that was set in the expectation. If the same input is set with different return values, they will be returned in the order the code has added them.

You’ll notice that, after the recording stage ?, we call GetSomeNumber with the b input, but the test will still pass, which means the order of the calls doesn’t matter.

NOTE If we wanted the order to matter, we could use a concept called ordered mocks, which are used to define the correct order in which calls and return values should be executed. You can find out more about ordered mocks on the Rhino Mocks website.

If we change the order of the last two asserts in the test (which both input a), the test will fail because the recording order matters when the input is the same for the expectations.