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