[rspec-users] respond_to? check in rspec-mocks
dchelimsky at gmail.com
Sat Aug 28 14:01:59 EDT 2010
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
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
> 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.
More information about the rspec-users