How do you write tests in rails that check implementation?

Koz et al,

I'm trying to write a patch for this ticket:

http://rails.lighthouseapp.com/projects/8994/tickets/1104-references_eager_loaded_tables-should-search-tables-in-join-clauses

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

Neat - I've been hitting that recently. Bit of a kludge but could you just look at the number of queries made (ie 1 for join based monster, number of associations + 1 in other cases) ?

Fred

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.