This is a long line; I'd like to see it broken into multiple lines.

Also, it seems to me that you should check the prepended module to see if it has a definition for this method rather than checking to see if the object has the method, for two reasons:

* `@object.method` can raise a name error.  It doesn't return true/false like you are doing here.  I don't think you want it to fail with a `NameError`, right?
* If the object responds to the message but the prepended module does not have a definition for it, we don't need to prepend our module.  The method call will bypass the prepended module (since it has no def) and go to the object's normal def and our normal methods will work.  Avoiding prepending a module unnecessarily is a good thing since it's a side effect we can't revert.

Here's what I think this should be:

``` ruby
def is_class_with_prepended_override?
  return false unless Class === @object
  prepended_modules.any? { |mod| mod.method_defined?(method_name) }
end

def prepended_modules
  object_singleton_class.ancestors.take_while { |anc| anc != object_singleton_class }
end
```

I didn't notice the `Class === @object` check before but I think that needs to be in the method name because if other objects can have prepended modules and this method would return false for them.  We only care if there is a prepend with an override so that's in the method name, too.

With this form, there are a couple additional tests I'd like to see:

* For classes with prepended modules that do not override the stubbed method, the ancestor chain is not modified by rspec-mocks (since there's no need).
* If the method is overriden in a prepended module but not in the first prepended module, it should still work to stub it.  (This will only pass because we look for any prepended module that defines the override, not just the first).

Anyhow, speaking of the `Class === @object` check...are you sure this is only needed for class objects?  Is it also needed for module objects?  What about any object that has prepended modules in its singleton class?  Even if those cases somehow work, we should add specs for them, since we want them to always work and it's unclear to me if they will work with your code.