On Mon, Nov 1, 2010 at 8:55 AM, Alexey Ilyichev <bluesman.a...@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 _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
