[rspec-users] respond_to? check in rspec-mocks

[David Chelimsky]

On Aug 28, 2010, at 11:32 AM, Myron Marston wrote:

>> My other objection is that we're dealing with a dynamic
>> language here, and there are going to be cases in which methods
>> are defined dynamically. For average users, this is likely not
>> a problem (as long as the check is done at the time the stub is
>> invoked rather than when the stub is defined)
> 
> I was originally thinking the checking would happen when the stub is
> defined, but I think you're right about it being better to check when
> the stub is invoked.
> 
>> I've also seen plenty of cases where respond_to fails to handle
>> a case that method_missing handles. In these cases, users would
>> get misleading information back, making things more confusing.
> 
> That's a valid point, but IMHO an object that overrides method_missing
> but not respond_to? is pretty poorly behaved object.  You're
> essentially breaking the semantics of how objects are expected to work
> in ruby.

Agreed, but in pretty much every case that I've seen this it's been in a 3rd party library that I am not in control of.

> I'd personally want an error or warning when I did this, so
> that I'm alerted to the problem and can go fix it by properly defining
> respond_to?.

Interesting side effect of this. I can see how this can help nudge a developer in the right direction.

>> With all this, there is one idea that I've floated that I'd be
>> open to: an audit flag which could be used to generate a report
>> separate from the spec run.
> 
> Would this report wind up in a separate file that I'd have to open and
> look at separately?

I think "separate from the spec run" mislead you as to my intention here. What I mean is that I don't want this to raise errors, but rather it would be part of the output, just like pending and failed examples.

> That would reduce the usefulness of this a lot, I
> think.
> 
> Instead, could we make it configurable?  That way people can set it up
> to fit their development workflow.  I've been thinking that this
> should be configurable, since people have a variety of development
> styles.  Here's some thoughts about how that configuration could work:
> 
> * In the RSpec.configure block, you set a default.  Something like
> config.undefined_method_stubs = :error/:warn/nil.
> * In a spec, you can disable this checking for any object, using
> something like object.allow_undefined_method_stubs!.  This would work
> well for an object that overrides method_missing, if you really don't
> want to also override respond_to?.
> * In a before(:each) block, you can modify the configuration for that
> example group using something like RSpec::Mocks.undefined_method_stubs
> = :error/:warn/nil.

I was resistant to the idea when it was simpler, but this additional complexity makes me even moreso :)

Without getting into a debate about its relative merits, here's what I'd really like to see: an API in the rspec-mocks framework that would allow you to extend it to do all this in a separate gem. Then you could build this, release it, refine it, etc.

What do you think would be necessary in rspec-mocks to support that?

> Note that your separate report idea could easily be accommodated here;
> it could be an additional allowed value to undefined_method_stubs
> (maybe :separate_report ?).

No need for a separate report - again - poor choice of words on my part.

> Myron