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.