Stephen Eley wrote:
On Sat, Oct 18, 2008 at 9:49 PM, Mark Thomson <[EMAIL PROTECTED]> wrote:
[...] What I've observed is that it behaves differently
if I include a "should_not_receive('...')" expectation somewhere in the
spec. In that case it seems that I can have as many "file.puts()" in the
component being tested as I like without specifying expectations for them,
and they pass just fine.
Hmm, that does seem weird. ... Maybe file a Lighthouse ticket with code samples
clearly showing failing and passing tests.
Will do.
It's not the presence of a
single should_receive that makes the mock want to know about every
message it gets. It's the fact that *it's a mock.* Unless you tell
them otherwise, that's just the way mocks work.
Thanks, I think that's really the key concept I've been missing. I see
how that changes the perspective on should_receive.
If you don't want to
have to specify everything, then that's what stubs are for.
I think I understand your point here, though am I right that a stub is
restricted to specifying only one response to any particular method? You
can't specify parameters in the way you do using :with in should_receive
on a mock. OTOH taking a different tack, it seems from the
documentation (http://rspec.info/documentation/mocks/) that the
:null_object option to mock() may allow you to leave some messages
unspecified. I'll check on this.
In view of this, I wonder if a better way to formulate this test
might be to say something like -
object.should_receive :method => :method_name, :with_each_of => [arg1,
arg2,... argN]
That's not a bad idea, but I suspect your tests in which you're
calling 'puts' over and over might be a bit of an edge case.
Yeah, I think that's true. I was actually trying to debug the spec,
rather than object being tested. Still, it has turned out to be a useful
learning exercise.
_______________________________________________
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
