Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,128 | Comments: 45,550

filter by tags archive

Rhino Mocks 3.5 Design DecisionsTo be strict or not?

time to read 1 min | 51 words

Here is an interesting problem. What should this piece of code do?

var stubSmsSender = MockRepository.GenerateStub<ISmsSender>();
// test code

Right now this is a no-op.

But since stubs are explicitly not mocks, they shouldn't be verified. Should I throw here? For something which is a test design decision?

More posts in "Rhino Mocks 3.5 Design Decisions" series:

  1. (30 Jun 2008) Getting closer to conclusion
  2. (29 Jun 2008) The role of Stub vs. Mock
  3. (29 Jun 2008) To be strict or not?


Chad Myers

I say "Yes, throw" or at least make it the default option.

I would say that the developer might be confused here about what a Stub does and so is trying to use it incorrectly. They will likely get a false positive in their test and continue on without any indication there's a problem.

Matt Hinze

Throw. Make it difficult to do the incorrect thing..

Jeremy Gray

Upon further thought while reading the subsequent post on the behaviour of stubs versus mocks, I think I need to clarify my "+1 for throwing" to instead say:

+1 for throwing from VerifyAllExpectations calls on stubs and mocks that do not have any expectations set on them.

(That way my preference is consistent regardless of how the whole stubs versus mocks behaviour thing goes ;)

Tim Barcz

Why throw? If you say make it difficult to do the incorrect thing, wouldn't a no-op be better than a thrown exception. In other words if the "wrong" thing has no side-effect (being a no-op), why is it the wrong thing at all?

Ayende Rahien

a) user may assume that this is a valid thing to do.

b) this is a bad test design

Scott Hanselman

throw new StubsAreNotMocksException();

Sidar Ok

Why does generate stub return a type that has the ability related to verification at all ? Can't we discard the method at all from generated stub?

Ayende Rahien


VerifyAllExpectation is an extension method on object, therefor, stubs get it as well

Ben Hall

It's a shame the stub object has this method, ideally they wouldn't. If this can't be changed then Scott's suggestion of throwing an StubsAreNotMocksException(); seems the most logical so they don't end up writing bad tests.

Glenn Kees

I am in agreement with Jeremy. If the person crafting the test is a making a call to verify expectations but they have not set any then an exception should be thrown. Perhaps in this case it should throw new NoExpectationsSet(); (to steal a line from Scott's playbook).


We should not forbid setting expectations on stubs. I know stubs are not mocks, but there are times that I want to just check if a method on a stub is called or not.

So +1 for throwing if any expectations is not set.

Comment preview

Comments have been closed on this topic.


  1. The worker pattern - 12 hours from now

There are posts all the way to May 30, 2016


  1. The design of RavenDB 4.0 (14):
    26 May 2016 - The client side
  2. RavenDB 3.5 whirl wind tour (14):
    25 May 2016 - Got anything to declare, ya smuggler?
  3. Tasks for the new comer (2):
    15 Apr 2016 - Quartz.NET with RavenDB
  4. Code through the looking glass (5):
    18 Mar 2016 - And a linear search to rule them
  5. Find the bug (8):
    29 Feb 2016 - When you can't rely on your own identity
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats