Unit Testing Mock/Stub definitions in Moq

Question

Any reading or advice I've been given on Unit Testing has always suggested a distinct difference between the definition of a Mock and a Stub. My current understanding of these definitions are as follows

Mock: A fake which will be used in your test to make a final assertion

Stub: A fake which will be used in your test to isolate a dependency but not be asserted

However, Moq appears to only allow the creation of Mocks. The Stub namespace in the framework appears to be depreciated with recommendations to use Mock.SetupXXX.

Am I missing something in my understanding of this? Or is there a general understanding that a mock object can infact be used as nothing more that a stub?

Perhaps I am being pedantic, it's just that I have always found language in programming to be very strict and prefer to get my usage of it correct, especially when other developers might be taking over a project.

Answer 1

imho its just that its kind of a silly discussion.

What matters is that you use the mocks/stubs to assert what you need to in the test, and don't assert what you don't.

Answer 2

Martin Fowler wrote a good article, Mocks Aren't Stubs, which I think makes the distinction clear.

Mocks are used for behavior verification, while stubs supply fake data and normally participate in state verification.

Answer 3

According to the Moq project site, Moq provides:

Granular control over mock behavior with a simple MockBehavior enumeration (no need to learn what's the theoretical difference between a mock, a stub, a fake, a dynamic mock, etc.)

The lack of distinction between mocks, stubs, and such is a deliberate design decision; A design decision which I, for one, prefer. If I need a true mock, I call Verify() on it. If not, there's no Verify(). I like the simplicity, and I haven't found myself missing the distinction between mock and stub.

Answer 4

Indeed, Moq can create true stubs. From the Moq Quick Start page:

* Setup a property so that it will automatically start tracking its value (also known as Stub):

  // start "tracking" sets/gets to this property
  mock.SetupProperty(f => f.Name);

  // alternatively, provide a default value for the stubbed property
  mock.SetupProperty(f => f.Name, "foo");


  // Now you can do:

  IFoo foo = mock.Object;
  // Initial value was stored
  Assert.Equal("foo", foo.Name);

  // New value set which changes the initial value
  foo.Name = "bar";
  Assert.Equal("bar", foo.Name);

* Stub all properties on a mock (not available on Silverlight):

  mock.SetupAllProperties();

IMHO, the distinctions between flavors of fakes is best thought of as a distinction between functions of those fakes rather than types of fakes, as a fake may take on multiple roles at once (e.g. can be a true mock and a saboteur all at once), and as no such distinction is necessary for using a mock framework. (I should blog about this!)