11

As I am using RhinoMocks version 3.6 and as I am not using Record-Replay and as I do not call Verify methods for asserting on mocks;

Can you explain what is the difference between very simply?

MockRepository.GenerateMock()
MockRepository.GeneratePartialMock()
MockRepository.GenerateStrictMock()

Note: I use .GenerateMock all the time to create my mocks and I assert method calls by providing arguments expectation already.

pencilCake
  • 51,323
  • 85
  • 226
  • 363

2 Answers2

20

The differences are explained in this article

If you create no expectations on a StrictMock, and a method gets called on the mock, an exception will be thrown.

If you create no expectations on a PartialMock, and a method gets called on the mock, nothing special happens. If that mock derives from a base class, the call bleeds through to the existing base implementation.

There is also something called a DynamicMock. If you create no expectations on a DynamicMock, and a method gets called on the mock, a stub method is called. If there was a return value, a default value (e.g. null or 0) is returned.

GenerateMock I believe creates a DynamicMock.

Ayende chose this default because he recommends an ideal of only using DynamicMock and Stub. StrictMock creates brittle tests, and usually violates the concept of only verifying one behavior per test.

See this article: http://ayende.com/wiki/Rhino%20Mocks%203.5.ashx#CreateMockisdeprecated,replacedbyStrictMockTheuseofStrictMockisdiscouraged

I've also seen him say that it is useful to start with strict mocks, and work your tests back down to dynamic mocks/stubs once you're comfortable with how your code-under-test is behaving. No link for that tho :)

Merlyn Morgan-Graham
  • 58,163
  • 16
  • 128
  • 183
0

I have to add that "the use of Strict Mock is discouraged" by the words of Ayende. http://ayende.com/wiki/Rhino+Mocks+3.5.ashx#CreateMockisdeprecated,replacedbyStrictMockTheuseofStrictMockisdiscouraged

He says:

Strict mocks will fail if something that is not expected will happen to them. In the long run, this means that any change to the code under test can break your tests, even if the change has nothing to do with what you are actually testing in this specific test.

I encourage the use of stubs and dynamic mocks instead.

Metro Smurf
  • 37,266
  • 20
  • 108
  • 140
Vackup
  • 652
  • 4
  • 11