Comments on: Rhino Mocks Examples, with a fix

By: Mathias

Mathias — Mon, 22 Mar 2010 05:17:46 +0000

Great post; I have struggled with exactly the same issue, and Rhino.Mocks API doesn’t help understand the difference between Mocks and Stubs, because they both support the same methods, and stubs fail silently. Personally, the aha moment for me came when I read Roy Osherove’s “The Art of Unit Testing”, where he states that a test could fail because of a Mock, but never because of a Stub. That doesn’t resolve the somewhat ambiguous API issues, but that helps in determining whether what you need is a Mock or a Stub!

By: Jon Kruger

Jon Kruger — Mon, 22 Mar 2010 02:14:42 +0000

I updated my original post to fix the problem that you pointed out in this post. Thanks for pointing that out.

Jon

By: Thomas Eyde

Thomas Eyde — Sun, 21 Mar 2010 12:56:04 +0000

@Arthur, we can always debate whether an api is broken or not. But extension methods can operate on different types. My argument is that GenerateMock and GenerateStub should return different types. When that’s the case, we can have extension methods which only operates on one of the types.

@Krzysztof, you are correct. It’s easy to make the same mistake in Moq. I don’t use Verify very often, so I didn’t know. In that respect, I should probably refrain from commenting.

One can also argue that the Moq api is broken. I don’t know the rationale behind Verifiable(), but from where I am sitting, every method should be so by default. It’s up to me to call Verify() at the end.

By: Ryan Svihla

Ryan Svihla — Sat, 20 Mar 2010 23:38:59 +0000

For the kinds of test I really prefer obj.AssertWasCalled(x=>x.WhateverMethod), Then I can write asserts against specific method calls. Also with this approach I never have to use Expect and I only need Stub for my return values.

Ayende has examples of the AssertWasCalled approach in many places but here is one:
http://ayende.com/Blog/archive/2008/05/16/Rhino-Mocks–Arrange-Act-Assert-Syntax.aspx

By: Artur Dorochowicz

Artur Dorochowicz — Fri, 19 Mar 2010 17:45:11 +0000

Expect, Assert…, Verify… are implemented as extension methods on object. That’s the only way you can make it work in C#.
So certainly, Rhino Mocks API is not broken.

By: MM

MM — Fri, 19 Mar 2010 14:41:20 +0000

@Krzysztof – But don’t you think that this “shortcoming” is a little bit more acceptable in Moq because there is only one type of fake? In Rhino Mocks, stub and mock are distinct types so why even put the verify methods on stubs? I think the Moq documentation makes it fairly clear that Verify() will only verify expectations marked as Verifiable (then again, maybe the Rhino Mocks docs make it clear that you should not verify stubs).

John Sonmez hit the nail on the head. The bottom is line is that this is a good reminder that we should always make sure that our tests fail when they are supposed to.

By: John Sonmez

John Sonmez — Fri, 19 Mar 2010 14:22:32 +0000

Good catch. I think the bigger problem is though it not this incidence, but of not making sure that a test can fail. I wrote about this here: http://simpleprogrammer.com/2010/03/05/the-ego-test/

I call it an “ego test”, because you can always run it and feel good.

The only way to really prevent these kinds of problems is to make sure you can make a test fail.

By: Jon Kruger

Jon Kruger — Fri, 19 Mar 2010 12:51:45 +0000

Interesting. I was trying to figure out the differences between GenerateStub() and GenerateMock() and you pointed out one that I missed. I know what the difference is between a stub and a mock (from an academic perspective), but in Rhino Mocks I find that I never use GenerateMock(). Now, I don’t ever use Expect() and VerifyAllExpectations(), I prefer AssertWasCalled() instead, but that’s just my preference (and probably why I never found this problem before).

Looks like I’ll have to go update my code (unless you want to send me a patch!).

By: Krzysztof Kozmic

Krzysztof Kozmic — Fri, 19 Mar 2010 11:48:20 +0000

Thomas

You can fall prey to this issue with MoQ as easily as with Rhino Mocks.

[Test]
public void Moq()
{
var mock = new Mock();

mock.Setup( m => m.GetFoo() ).Returns( 34 );

//mock.Object.GetFoo();

mock.Verify();
}

public interface IFoo
{
int GetFoo();
}

This test will pass although it clearly shouldn’t (it does what I told it to, not what I wanted it to do).

It’s your choice if you like one framework over another but it has nothing to do with the issue at hand.

By: Thomas Eyde

Thomas Eyde — Fri, 19 Mar 2010 08:54:32 +0000

Or we can use a mocking framework with a lesser confusing api. My favourite for the moment is Moq. I haven’t used Rhino Mock since its Record / Replay days, and I failed miserably using that pattern.

I can relate to Stubs aren’t Mocks, but why should the framework care? For me, the test dummy is a stub when I use it as a stub. If I later choose to use it as a mock, then it is a mock.

We can debate this issue for as long as we want, but the fact remains that the Rhino Mock API is broken: The non-working VerifyAllExpectations()-method should never have been there in the first place.