Rhino Mocks Record Playback syntax

rhino-mocks

Help, can anyone help out and explain the purpose of the Rhino Mocks 'Record' scope?

I assumed that that the expectation set within the scope would only be verified but it seems as soon as you create the mock object, Rhino Mocks is in 'record mode' so I'm now unsure of the purpose of the Record scope.

Here's an example I have:

    private static void SomeTest()
    {
        MockRepository mockRepository = new MockRepository();
        ISomeInterface test = mockRepository.StrictMock<ISomeInterface>();

        test.Bar();

        using (mockRepository.Record())
        {
            Expect.Call<string>(test.GetFoo()).Return("Hello");
        }

        using (mockRepository.Playback()) 
        {
           test.GetFoo();
        }
    }

    public interface ISomeInterface
    {
        string GetFoo();
        void Bar();
    }

This test would fail because there is an expectation that Bar should be called. Is it because I've created a StrictMock and not Dynamic?

Best Answer

This test will fail because there is no expectation that Bar() would be called, but it was called.

To answer your question, yes, it is because you have a strict mock. If you change to a DynamicMock, it will ignore everything except the expectations that you actually set. I would highly recommend using DynamicMocks wherever possible, as StrictMocks are actually quite brittle and tend to end up being a lot of hassle.

As for Record/Replay, it is not automatically in Record mode if you're using a concrete MockRepository. It's just the nature of the StrictMock that looks for anything being called that was outside of expectations, no matter when.

Related Solutions

What are the differences between mocks and stubs on Rhino Mocks

As per this

... Put simply there is a difference between Mock and Stub objects and RhinoMocks recognizes that allowing us to write tests that better state their purpose.

Mock objects are used to define expectations i.e: In this scenario I expect method A() to be called with such and such parameters. Mocks record and verify such expectations.

Stubs, on the other hand have a different purpose: they do not record or verify expectations, but rather allow us to “replace” the behavior, state of the “fake”object in order to utilize a test scenario ...

Rhino Mocks – Stub .Expect vs .AssertWasCalled

What is your test trying to achieve?

What behaviour or state are you verifying? Specifically, are you verifying that the collaborator (data) is having its ListCount method called (interaction based testing), or do you just want to make ListCount return a canned value to drive the class under test while verifying the result elsewhere (traditional state based testing)?

If you want set an expectation, use a mock and an expectation: Use MockRepository.CreateMock<IMyInterface>() and myMock.Expect(x => x.ListCount())

If you want to stub a method, use MockRepository.CreateStub<IMyInterface>() and myStub.Stub(x => x.ListCount()).

(aside: I know you can use stub.AssertWasCalled() to achieve much the same thing as mock.Expect and with arguably better reading syntax, but I'm just drilling into the difference between mocks & stubs).

Roy Osherove has a very nice explanation of mocks and stubs.

Please post more code!

We need a complete picture of how you're creating the stub (or mock) and how the result is used with respect to the class under test. Does ListCount have an input parameter? If so, what does it represent? Do you care if it was called with a certain value? Do you care if ListCount returns a certain value?

As Simon Laroche pointed out, if the Manager is not actually doing anything with the mocked/stubbed return value of ListCount, then the test won't pass or fail because of it. All the test would expect is that the mocked/stubbed method is called -- nothing more.

To better understand the problem, consider three pieces of information and you will soon figure this out:

What is being tested
In what situation?
What is the expected result?

Compare: Interaction based testing with mocks. The call on the mock is the test.

[Test]
public void calling_ListCount_calls_ListCount_on_DAL()
{
   // Arrange
   var dalMock = MockRepository.Mock<IDAL>();
   var dalMock.Expect(x => x.ListCount()).Returns(1);
   var manager = new Manager(dalMock);

   // Act
   manager.ListCount();

   // Assert -- Test is 100% interaction based
   dalMock.VerifyAllExpectations();   
}

State based testing with a stub. The stub drives the test, but is not a part of the expectation.

[Test]
public void calling_ListCount_returns_same_count_as_DAL()
{
   // Arrange
   var dalStub = MockRepository.Stub<IDAL>();
   var dalStub.Stub(x => x.ListCount()).Returns(1);
   var manager = new Manager(dalMock);

   // Act
   int listCount = manager.ListCount();

   // Assert -- Test is 100% state based
   Assert.That(listCount, Is.EqualTo(1),
       "count should've been identical to the one returned by the dal!");
}

I personally favour state-based testing where at all possible, though interaction based testing is often required for APIs that are designed with Tell, Don't Ask in mind, as you won't have any exposed state to verify against!

API Confusion. Mocks ain't stubs. Or are they?

The distinction between a mock and a stub in rhino mocks is muddled. Traditionally, stubs aren't meant to have expectations -- so if your test double didn't have its method called, this wouldn't directly cause the test to fail.

... However, the Rhino Mocks API is powerful, but confusing as it lets you set expectations on stubs which, to me, goes against the accepted terminology. I don't think much of the terminology, either, mind. It'd be better if the distinction was eliminated and the methods called on the test double set the role, in my opinion.

Best Answer

Related Solutions

What are the differences between mocks and stubs on Rhino Mocks

Rhino Mocks – Stub .Expect vs .AssertWasCalled

Related Topic