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: 10 | Comments: 33

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. Production postmortem: The case of the memory eater and high load - 3 days from now
  2. Production postmortem: The case of the lying configuration file - 4 days from now
  3. Production postmortem: The industry at large - 5 days from now
  4. The insidious cost of allocations - 6 days from now
  5. Find the bug: The concurrent memory buster - 7 days from now

And 4 more posts are pending...

There are posts all the way to Sep 10, 2015


  1. Find the bug (5):
    20 Apr 2011 - Why do I get a Null Reference Exception?
  2. Production postmortem (10):
    14 Aug 2015 - The case of the man in the middle
  3. What is new in RavenDB 3.5 (7):
    12 Aug 2015 - Monitoring support
  4. Career planning (6):
    24 Jul 2015 - The immortal choices aren't
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats