A colleague just came in and asked me about a problem he was having with
stub_render, which reminded me of another issue he had a week or so ago,
which seems related.
Let me start with the earlier issue.
He was trying to write specs for a method which sends the same message
possibly multiple times, but with different arguments under different
calling conditions. He wanted to write
something.should_receive(:foo).with(someArguments)
except that the other calls would cause this to fail. He was trying to
get
this to work by specifying ordered expectations but this was getting
messy.
What he really wanted was some kind of paired mock and stub, so that the
expectation that the method would be invoked with the given arguments
could
be verified, but the other calls would just be stubbed.
Now after today’s question, and understanding how expect_render and
mock_render differ from normal expectations, these seem to be related.
Maybe we should be able to say something like:
something.expects(:foo).with(someArguments).with(otherArguments).otherwise(:stub)
something_else.expects(:bar).with(arguments).otherwise(:pass) # if
the
arguments don’t match pass the method to the real object
Which is really just a strawman to see if a discussion ensues. There
are
other issues like providing return values, and perhaps optionally
passing a
method through after verification that it was called with the expected
arguments.
Comments?
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/