On Aug 9, 2010, at 7:42 AM, Matt Wynne wrote: > > On 9 Aug 2010, at 13:04, David Chelimsky wrote: > >> >> On Aug 9, 2010, at 6:37 AM, Matt Wynne wrote: >> >>> >>> On 9 Aug 2010, at 01:54, David Chelimsky wrote: >>> >>>> >>>> On Aug 8, 2010, at 11:13 AM, Matt Wynne wrote: >>>> >>>>> >>>>> On 8 Aug 2010, at 16:53, David Chelimsky wrote: >>>>> >>>>>> On Aug 8, 2010, at 10:40 AM, Matt Wynne wrote: >>>>>>> On 8 Aug 2010, at 16:38, David Chelimsky wrote: >>>>>>>> On Aug 7, 2010, at 4:10 PM, David Chelimsky wrote: >>>>>>>> >>>>>>>>> Hey all, >>>>>>>>> >>>>>>>>> It turns out that if you have >>>>>>>>> >>>>>>>>> * Rails (2 or 3) >>>>>>>>> * Ruby-1.9 >>>>>>>>> * a model named Message >>>>>>>>> * let(:message) or def message in an example group >>>>>>>>> * a Rails assertion in an example in that group >>>>>>>>> * note that rspec-rails' matchers delegate to Rails' assertions >>>>>>>>> >>>>>>>>> You'll get an error saying "wrong number of arguments (1 for 0)" >>>>>>>>> >>>>>>>>> This is because the rails assertion, which, when running with >>>>>>>>> Ruby-1.9, delegates to Minitest::Assertions#assert_block, which >>>>>>>>> delegates to a message() method that it defines. So the message() >>>>>>>>> method defined by let() overrides the message() method in the >>>>>>>>> Assertions module, and results in unexpected and undesirable outcomes. >>>>>>>>> >>>>>>>>> So - what should we do? I don't think changing Minitest is really an >>>>>>>>> option, as too many assertion libraries already wrap Minitest >>>>>>>>> assertions. I don't think RSpec should be in the business of >>>>>>>>> monitoring methods end-users define to make sure they're not >>>>>>>>> overriding pre-existing methods (what if you override a method >>>>>>>>> intentionally?). The only thing I'm left with is document this >>>>>>>>> particular case and hope for the best, but that feels unsatisfactory >>>>>>>>> as well. >>>>>>>>> >>>>>>>>> Recommendations? Words of wisdom? >>>>>>>> >>>>>>>> FYI - here's the issue that spawned this thread: >>>>>>>> http://github.com/rspec/rspec-rails/issues/152 >>>>>>> >>>>>>> Can you use the Assertions module some other way than mixing it into >>>>>>> the example (thereby polluting it with the Assertions module's methods?) >>>>>> >>>>>> I like the idea in the abstract, but most of the rails assertions rely >>>>>> on some state that is local to the example (@response, @controller, >>>>>> @request, etc, etc). RSpec _could_ gather up all those instance >>>>>> variables and pass them into an assertion-wrapper object, but then it >>>>>> would be highly coupled to that implementation and would lead us down a >>>>>> familiar and unfriendly path of forcing rspec-rails releases for every >>>>>> rails release. That's a world I hope to leave behind with Rails 3 :) >>>>> >>>>> So leave the rails assertions mixed into the example, but forward all the >>>>> calls to the MiniTest::Assertions methods to some other object that has >>>>> them mixed in. Won't that work? >>>> >>>> Here's a prototype implementation: >>>> http://github.com/rspec/rspec-rails/commit/0cd384536cf532435ec8f290a9c357b60872acd7 >>>> >>>> It's on a branch >>>> (http://github.com/rspec/rspec-rails/tree/assertion-delegate) because I'm >>>> not convinced this is the right way to go yet, but I'd like some feedback >>>> from anyone who wishes to peruse and comment. >>> >>> Yeah, that's what I was talking about. Couple of thoughts / questions: >>> >>> I'm still not clear why you need to copy the instance variable over though >>> - do the rails assertions get monkey-patched into the >>> Test::Unit::Assertions module then? >> >> No - holdover from exploratory session. >> >>> Also, how come there's nothing in the specs about the #message method that >>> caused all this? >> >> Good point. >> >> New patch: >> http://github.com/rspec/rspec-rails/commit/86600313462638e7becc726e53f1bc67af108667 > > This is like an extremely sluggish kind of pair programming! > > What do you think of it now? Is it growing on you? What worries you about it?
Not sure yet. On one hand it feels sort of unnecessary, but on the other, it does solve this particular anomaly. I'm going to sit on it for a day or two and see if any specific arguments against come to mind. In the mean time, other opinions would be welcome. Cheers, David > >> >>>> Thanks, >>>> David >>>> >>>>>> It would also eliminate the option to use the Rails assertions directly >>>>>> in examples. >>>>>> >>>>>> Oh, well :) >>>>>> >>>>>>> cheers, >>>>>>> Matt >>>>>>> >>>>>>> http://blog.mattwynne.net >>>>>>> +44(0)7974 430184 >>>>>> >>>>>> _______________________________________________ >>>>>> rspec-users mailing list >>>>>> rspec-users@rubyforge.org >>>>>> http://rubyforge.org/mailman/listinfo/rspec-users >>>>> >>>>> cheers, >>>>> Matt >>>>> >>>>> http://blog.mattwynne.net >>>>> +44(0)7974 430184 >>>>> >>>>> _______________________________________________ >>>>> rspec-users mailing list >>>>> rspec-users@rubyforge.org >>>>> http://rubyforge.org/mailman/listinfo/rspec-users >>>> >>>> _______________________________________________ >>>> rspec-users mailing list >>>> rspec-users@rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/rspec-users >>> >>> cheers, >>> Matt >>> >>> http://blog.mattwynne.net >>> +44(0)7974 430184 >>> >>> _______________________________________________ >>> rspec-users mailing list >>> rspec-users@rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-users >> >> _______________________________________________ >> rspec-users mailing list >> rspec-users@rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users > > cheers, > Matt > > http://blog.mattwynne.net > +44(0)7974 430184 > > _______________________________________________ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
