Ayende @ Rahien

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

ayende@ayende.com

+972 52-548-6969

, @ Q c

Posts: 5,968 | Comments: 44,489

filter by tags archive

Rhino Mocks 3.5 Design DecisionsTo be strict or not?


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

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

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?

Comments

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

Sidar,

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).

Bahador

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.

FUTURE POSTS

No future posts left, oh my!

RECENT SERIES

  1. Career planning (6):
    24 Jul 2015 - The immortal choices aren't
  2. Production postmortem (4):
    23 Jul 2015 - The case of the native memory leak
  3. API Design (7):
    20 Jul 2015 - We’ll let the users sort it out
  4. What is new in RavenDB 3.5 (3):
    15 Jul 2015 - Exploring data in the dark
  5. The RavenDB Comic Strip (3):
    28 May 2015 - Part III – High availability & sleeping soundly
View all series

RECENT COMMENTS

Syndication

Main feed Feed Stats
Comments feed   Comments Feed Stats