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. 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 >> [email protected] >> http://rubyforge.org/mailman/listinfo/rspec-users > > cheers, > Matt > > http://blog.mattwynne.net > +44(0)7974 430184 > > _______________________________________________ > rspec-users mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/rspec-users _______________________________________________ rspec-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/rspec-users
