Marnen Laibow-Koser wrote: > And there's an argument to be made that since the AR framework is part > of an AR class, it must be respected -- and hit *some* state-preserving > DB-like thing -- to properly unit test an AR class.
This is the kind of muddling of concepts that I think Rails encourages. The idea that "Model == Database Thingy". At every opportunity I encourage developers to start their apps with bare, pure Ruby models and only add "< ActiveRecord::Base" in a later iteration. This practice helps to start thinking of your objects purely in terms of how they model your domain - which is how OO is supposed to work. After you spend some time looking at the models strictly in terms of their capabilities and responsibilities, then you add in persistence. Usually this means that you add a collaborator, which is some kind of OO/RDB mapping system. But it's still just another collaborator, with neat, clean division of responsibilities. Of course, AR makes it harder to think of it as a collaborator because you have to inherit from it and it adds all sorts of methods to self and imposes arbitrary rules like "no initializers". But if you are careful you can still think of it as a (rather pushy) collaborator and structure your tests accordingly - separating the tests of persistence from the tests of logic. I'll add a post about the how and the why and the benefits of this kind of strict separation to my queue on Virtuous Code. -- Avdi -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" 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-talk?hl=en.
