What are the differences between mocks and stubs on Rhino Mocks

mockingrhino-mocks

I haven't play enough with this and usually use mocks, but I wonder what are the differences between this two and when to use one or the other on Rhino Mocks.

Update:

I also found the answer to my question in Ayende's words:

The difference between stubs and mocks

You can get the actual definition of the these terms in this article: Mocks Aren't Stubs. I want to focus on the difference from the point of view of Rhino Mocks.

A mock is an object that we can set expectations on, and which will verify that the expected actions have indeed occurred. A stub is an object that you use in order to pass to the code under test. You can setup expectations on it, so it would act in certain ways, but those expectations will never be verified. A stub's properties will automatically behave like normal properties, and you can't set expectations on them.

If you want to verify the behavior of the code under test, you will use a mock with the appropriate expectation, and verify that. If you want just to pass a value that may need to act in a certain way, but isn't the focus of this test, you will use a stub.

IMPORTANT: A stub will never cause a test to fail.

Best Answer

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 ...

From Martin Fowler about Mock and Stub

Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production

Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it 'sent', or maybe only how many messages it 'sent'.

Mocks are what we are talking about here: objects pre-programmed with expectations which form a specification of the calls they are expected to receive.

From xunitpattern:

Fake: We acquire or build a very lightweight implementation of the same functionality as provided by a component that the SUT depends on and instruct the SUT to use it instead of the real.

Stub : This implementation is configured to respond to calls from the SUT with the values (or exceptions) that will exercise the Untested Code (see Production Bugs on page X) within the SUT. A key indication for using a Test Stub is having Untested Code caused by the inability to control the indirect inputs of the SUT

Mock Object that implements the same interface as an object on which the SUT (System Under Test) depends. We can use a Mock Object as an observation point when we need to do Behavior Verification to avoid having an Untested Requirement (see Production Bugs on page X) caused by an inability to observe side-effects of invoking methods on the SUT.

Personally

I try to simplify by using : Mock and Stub. I use Mock when it's an object that returns a value that is set to the tested class. I use Stub to mimic an Interface or Abstract class to be tested. In fact, it doesn't really matter what you call it, they are all classes that aren't used in production, and are used as utility classes for testing.

C# – mixing stubs and mocks in rhino

This should do it, assuming that your method has an int argument.

IDal dalMock = MockRepository.GenerateMock<IDal>();

// setup mock to return the emptyDataSet for any argument    
dalMock
  .Stub(x => x.GetDataSet(Arg<int>.Is.Anything))
  .Return(emptyDataSet)
  .Repeat.Any();

sut.Execute()

// assert that the argument had been 7
dalMock.AssertWasCalled(x => x.GetDataSet(Arg<int>.Is.Equal(7))

Documentation of argument constraints. (I wrote this chapter, so you can ask me if you don't understand ;-)

Using .NET 2.0 it would look something like this:

MockRepository mocks = new MockRepository();
IDal dalMock = mocks.CreateDynamicMock<IDal>();

// expect the correct argument
Expect.Call(dalMock.GetDataSet(Arg<int>.Is.Equal(7)))
  .Return(emptyDataSet)
  .Repeat.Once();

// setup mock to return the emptyDataSet for any argument    
SetupResult.For(dalMock.GetDataSet(Arg<int>.Is.Anything))
  .Return(emptyDataSet)
  .Repeat.Any();

sut.Execute()

// assert that the argument had been 7
mocks.VerifyAll();

Not 100% sure if it works, but it should.

You can also try this:

// setup mock to return the emptyDataSet for any argument    
SetupResult.For(dalMock.GetDataSet(Arg<int>.Is.Anything))
  .Do((GetDataSetDelegate)delegate(int i)
    {
      Assert.AreEqual(7, i);
    }
  .Return(emptyDataSet)
  .Repeat.Any();

sut.Execute()

Do is executed when the mock is called. It requires a delegate with the exact same interface as the mocked method. Because of syntactical reasons of .NET 2.0, you need to cast it to the right delegate type, so you need to declare it first (GetDataSetDelegate in this case).

Note for Rhino 3.5 users: there is a much more convenient way to be called: WhenCalled just takes a lambda as argument, but has to be implemented differently.

With Do or WhenCalled respectively you can implement argument assertions when the mock is called.

Best Answer

Related Solutions

What’s the difference between faking, mocking, and stubbing

From Martin Fowler about Mock and Stub

From xunitpattern:

Personally

C# – mixing stubs and mocks in rhino

Related Topic