+972 52-548-6969
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
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:
- (30 Jun 2008) Getting closer to conclusion
- (29 Jun 2008) The role of Stub vs. Mock
- (29 Jun 2008) To be strict or not?
Comments
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.
Throw. Make it difficult to do the incorrect thing..
+1 for throwing
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 ;)
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?
a) user may assume that this is a valid thing to do.
b) this is a bad test design
throw new StubsAreNotMocksException();
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?
Sidar,
VerifyAllExpectation is an extension method on object, therefor, stubs get it as well
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.
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