On Rhino.Mocks VerifyAllExpectations Vs AssertWasCalled

After reading my Rhino.Mocks Quick Reference post, a colleague and I had a discussion about the proper way to validate expectations in Rhino.Mocks. Specifically, he questioned if my use of .VerifyAllExceptions() was correct for the ArrangeActAssert syntax, or, as he proposed, is it the “old” syntax, being replaced by the .AssertWasCalled() methods.

Since this is a person I respect, I decided not to smite him and instead took a mental note to do some quick google searches research. Having failed to actually find Ayende’s opinion on the matter in the first 5 minutes, I did come across this post, which raised a point I did not realize had forgotten:

In Rhino Mocks, expectations on stubs are not verified; only mocks are verified. If an object is created with GenerateStub instead of GenerateMock, then its VerifyAllExpectations method doesn’t do anything. This is non-obvious because the AssertWasCalled and AssertWasNotCalled methods on a stub will behave the way you want them to.
In Rhino Mocks, a stub can keep track of its interactions and assert that they happened, but it cannot record expectations and verify they were met. A mock can do both these things. 

So, if you are using a Stub, you must not use .VerifyAllExpectations(), because it will always pass.

Now, one might argue (and many, many on the Internet do argue) that a Stub should not have any expectations, so you shouldn’t be calling either method. Stubs are for providing inputs to allow the code under test to run and limit your test to just the code under test, while Mocks are uses to validate behaviour. (they are one of the tests). 

If someone does have a link to Ayende’s opinion, please post as a comment or email/tweet me. I’ll update this post if I find it.

Update: found this (http://ayende.com/wiki/Rhino+Mocks+3.5.ashx#ExpectExtensionMethod) where it seems Ayende expects people to use either case (ie: he doesn’t state here that one is “proper”).  I still seem to remember a blog he wrote stating a preference for one over the other, but I haven’t yet found it).

  • I think the main confusion (for me) is the difference between mocks and stubs in Rhino. While this might be useful for theoretical discussions, I see no need for a framework to differentiate.

    When you a set up expectations on a mock, you are actually doing two things: (1) setting up an expectation to be verified later and (2) setting up a return value (I think this is optional?). While I’m all for saving lines of code where possible, it seems cleaner that these two operations should be handled with two separate instructions.

    Since a stub is “recording” what is happening to it anyway, and I can make assertions on it after the fact, setting up expectations in the “Arrange” phase has no real advantage that I can see. It is also somewhat reminiscent of the old “Record/Replay” syntax, which is why I made the comment in the first place.

    I like RhinoMocks and have used it for a long time, but it needs a new release that cleans up the API and gets rid of the “stub vs. mock” concept, which is probably confusing to new users (it’s clearly confusing to old users :)). We chose Moq for our most recent project and we have no regrets to date.

  • Anonymous

    Nice article :-)

  • Muralidhar

    Great Article, Thanks :-)