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

Myron Marston 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
= :error/:warn/nil.

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 mailing list