In that particular example the real problem is the use
of Expect rather than Stub. Rhino.Mocks has facilities
for both, and you should use Stub unless you want to
Assert on interaction.
This is yet another example of why the Expect/Verify
method should be stricken from mocking frameworks. No
matter how much you preach the one-assert-per-test
guideline, people are just not going to understand how
expect/verify fits in.
As soon as you make them add a line at the end of the
test to assert a method was called their intentions
become more clear and they will have been guided to
doing that by choice rather than bad sample tests.
Being relatively new to mocking, I'm guilty of this
myself. It's not intuitive to a new user when to use
fakes, stubs, mocks, dynamic mocks, static mocks, etc
etc etc. And there is a big shift in thinking between
state-based testing (x goes in, y comes out) and
behavior-based testing (to do x, a, b, and c must be
called, bu don't worry about what the actual result ends
up being as long as that is satisfied). I think in a lot
of my tests I end up combining the two, but I can see
how this can be a bad thing, resulting in
overcomplicated or overly long tests.
As you say being clear about whether you are mocking or
stubbing is key.