[rspec-users] Fwd: Issue with AR::Base descendants with certain argument

Bira u.alberton at gmail.com
Mon Nov 1 07:44:29 EDT 2010


On Mon, Nov 1, 2010 at 8:55 AM, Alexey Ilyichev <bluesman.alex at gmail.com> wrote:
> David, I got your point, however I find behavior in version 1.3.1
> inconsistent. In my opinion, if I stub a method with a certain parameter
> value, and then call with another value, it should either delegate to
> original method, return nil, or throw an exception. I'd be happy with either
> of these. But what it actually does is delegating to the original method in
> the superclass, which doesn't make sense to me at all.

<...>

> And also, it behaved differently in 1.2.9. My original problem arisen after
> updating to 1.3.1
>

I have a similar problem here at work. We use a variant of the
rails-settings plugin, which stores configuration settings in a DB
table and relies heavily on a class-level method_missing to fetch
them. So, for example, you could call Settings.welcome_message and
expect to get a string back.

Our specs stub specific methods from this class often, to test how the
application behaves given different values for them. The stubs work
properly the first time, but afterwards they somehow go missing. On
1.3.0, this caused the actual method to be called, which is incorrect,
but went unnoticed as the specs still passed.

On 1.3.1, due to commit 2753b492e00078c92f9fe3b9e879ea83e3536753, the
"missing" stub method is now actually called on the superclass, rather
than on the class itself. So we get lots of failures of the "undefined
method welcome_message for ActiveRecord::Base".

I tried to reproduce this on rspec alone, but there things seemed to
work perfectly. So it looks like rspec-rails plays a part on this as
well. I'll see if I can reproduce it there.


-- 
Bira
http://compexplicita.wordpress.com
http://compexplicita.tumblr.com


More information about the rspec-users mailing list