> 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 respond_to?. > 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 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. 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 ?). Myron _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
