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