Rhino Mocks overwriting stubs possible?

Question

I have this problem, which may be a bug in Rhino Mocks 3.5:

stubObj = MockRepository.GenerateStub(IObject);

stubObj.Stub(a=>a.Get()).Return (Guid.Empty); //1.stub
stubObj.Stub(a=>a.Get()).Return (Guid.NewGuid()); //2.stub, should overwrite the first one?

this:

var value = stubObj.Get();

returns Guid.Empty, is this the correct behavior?

I don't quite understand why you want to 'overwrite' an expectation. The behavior seems okay to me. Just a speculation from me: If you are trying to re-use or recycle a stub for another assertion, then you should not do that. That would not be a good practice for writing tests. — Theo Lenndorff, Feb 28 '10 at 20:00

score 8 · Answer 1 · answered Feb 19 '10 at 10:16

8

If you want to return the empty guid a known number of times, the only thing you have to do is to tell RhinoMocks how many times to repeat it, e.g. the following test passes:

[Test]
    public void MultipleStubsTest()
    {
        var testMock = MockRepository.GenerateMock<ITest>();
        testMock.Stub(x => x.Get()).Return(Guid.Empty).Repeat.Once();
        testMock.Stub(x => x.Get()).Return(Guid.NewGuid());

        Assert.AreEqual(Guid.Empty, testMock.Get());
        Assert.AreNotEqual(Guid.Empty, testMock.Get());
    }

if you don't know how many times Get() will be called before the guid should change, than you can always use .Do() and code it there (please let me know if you need more details).

answered Feb 19 '10 at 10:16

Grzenio

35,875
47
158
240

I would **love** som more details on how I can use `Do()` if I don't know the number of times `Get()` will be called. I cannot replace `testMock` with a new mock, so instead I need to change the value that `Get()` returns. – smoksnes Aug 18 '16 at 05:47
Nevermind. I found the answer here. http://stackoverflow.com/questions/13918281/why-cant-i-change-the-return-value-in-a-rhino-mocks-stub-object – smoksnes Aug 18 '16 at 05:51

Ruben Bartelink · Answer 2 · 2010-02-19T13:47:10.337

1

You have just programmed the Stub object for two separate calls. If you call stubObj.Get again, you should get what Guid.NewGuid generated. You can prepare your fake object for any number of invocations of different kinds. For this reason, it doesnt make sense to expect the last .Stub call for a given invocation to replace previous .Stubbings of that call.

In your test code, which should be short and neat, there should never be a case where you need to 'undo' such programming of the mock in the way you seem to want to do.

If what needs to be returned is a conditional thing which varies depending on other bits of your test code across multiple calls to this block of code, the last thing you want is magic happening to make readers have to figure out what you meant. If it's conditional, you should make it clear.

And then, when you've made it clear, refactor it out as you should not have Conditional Logic in Tests (see xUnit Test Patterns)

edited Feb 19 '10 at 13:47

answered Feb 19 '10 at 09:40

Ruben Bartelink

59,778
26
187
249

a nitpick: `Stub` only sets behavior, not expectations. It's unfortunate that RhinoMocks supports both record-replay-verify (where you would record expectations) and arrange-act-assert (where you would use stubs and separate assertions), it makes things very complicated to explain. – Wim Coenen Feb 19 '10 at 12:56
@wcoenen: I dont use RhinoMocks, and the cruft and confusion caused by the multiple models and other legacy cruft is the primary reason (I choose Moq as it's got one opinion). The main thing I wanted to get across in my response was that in general you're preparing for multiple calls and hence it would be surprising in most cases for the framework to go collapsing all of them down to one in the way that the questioner seems to be suggesting would make sense) . I'm happy for anyone to go in and edit my terminology to make it less confusing for RM users. – Ruben Bartelink Feb 19 '10 at 13:41
@wcoenen: I've tried to remove abuse of RM terminology by replacing it with generic terminology and would appreciate any additional edits to make things less confusing. (Was reading chapter 6 or PragProg's Unit Testing book [published 2007] in recent days which relegates RhinoMocks to a sidebar [and doesnt mention Moq] which won't help with the termninology. (I still stand over my main point which is that one shouldn't be modifying a stub/mock setup as part of a test or otherwise engaging in any such Conditional Logic In Test antipatterns.) – Ruben Bartelink Feb 19 '10 at 13:51

score 1 · Answer 3 · answered Jul 26 '10 at 00:30

That's how you would do it. It passes on my machine.

    [TestMethod]
    public void Test()
    {
        stubObj = MockRepository.GenerateMock<IGuidTest>();

        stubObj.Stub(a => a.Get()).Repeat.Times(1).Return(Guid.Empty);
        stubObj.Stub(a => a.Get()).Repeat.Times(1).Return(Guid.NewGuid()); 

        Assert.AreEqual(Guid.Empty, stubObj.Get());
        Assert.AreNotEqual(Guid.Empty, stubObj.Get());

    }
    public IGuidTest stubObj;
    public interface IGuidTest
    {
        Guid Get();
    }

score 0 · Answer 4 · answered Feb 19 '10 at 08:49

0

The following tests should pass:

// arrange
var stubObj = MockRepository.GenerateStub<IObject>();
stubObj.Stub(a => a.Get())
       .Return(Guid.Empty);
// act
var value = stubObj.Get();
// assert
Assert.AreEqual(Guid.Empty, value);

And if you want to return a new guid:

// arrange
var stubObj = MockRepository.GenerateStub<IObject>();
stubObj.Stub(a => a.Get())
       .Return(Guid.NewGuid());
// act
var value = stubObj.Get();
// assert
Assert.AreNotEqual(Guid.Empty, value);

answered Feb 19 '10 at 08:49

Darin Dimitrov

1,023,142
271
3,287
2,928

thanks, but I dont want to arrange it once again just to change stubbed return value. Is there a kind of replay() method that replays just the specified stub object? – David Feb 19 '10 at 09:19

score 0 · Answer 5 · answered Mar 15 '18 at 13:51

You have the option to reset all expectations if that seems appropriate.

    public interface IObject { Guid Get(); }

    [Test]
    public void OverwriteStubTest()
    {
        Guid ret = Guid.NewGuid();
        var stub = MockRepository.GenerateMock<IObject>();

        stub.Stub(a => a.Get()).Return(Guid.Empty);
        Assert.AreEqual(Guid.Empty, stub.Get());

        //Reset all expectations on this mock object
        stub.BackToRecord(); 
        stub.Stub(a => a.Get()).Return(ret);
        stub.Replay();
        Assert.AreEqual(ret, stub.Get());
    }

score -1 · Answer 6 · edited May 23 '17 at 11:46

-1

Yes, this is the expected behavior. Writing the expectations/stubs in that way tells the mocking framework to return Guid.Empty the first time the Get() method is called and return Guid.NewGuid() the second time it is called.

Here are a few ways to "overwrite" the first expectation with the second: How to change behaviour of stubs?

edited May 23 '17 at 11:46

Community

1
1

answered Jul 01 '12 at 21:38

MoMo

8,149
3
35
31

NO, without .Repeat.Once option, stub return only the first stub (Empty) and never the second (new). – Glauco Cucchiar Apr 07 '17 at 07:29

Rhino Mocks overwriting stubs possible?

6 Answers6