I haven't look at the implementation of this, so I can only answer generally. However, at some point in there the code must call different methods based on which finder strategy it chooses. You could identify the point at which the code paths diverge and mock the unique methods calls for each path. Perhaps this is what you mean by using expectations?
Of course, I suspect you (David) are familiar with my particular opinion on digging around in implementation details with unit tests. If you could extract the code responsible for choosing the finder strategy in such a way that you could use or test it in isolation, then that would be the ideal. On Sep 24, 8:14 pm, David Stevenson <[EMAIL PROTECTED]> wrote: > Koz et al, > > I'm trying to write a patch for this ticket: > > http://rails.lighthouseapp.com/projects/8994/tickets/1104-references_... > > I want to make rails better at guessing which style of :include to > execute (pre-2.1 vs 2.1+), but I don't see any tests like what I'm > trying to test in eager_test.rb > > So how would I test that rails is doing the :include one way vs > another? Both would work and produce identical results at the end, so > it seems not possible to functionally test this. Yet all these tests > check the function of finders, rather than unit testing the individual > support methods (I could obviously test this by unit testing > references_eager_loaded_tables? method). Normally here, I'd use > expectations to see that things are working under the hood the right > way... > > Thanks guys! > > -David Stevenson > Pivotal Labs --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
