Rick R wrote in post #967105: > On Tue, Dec 7, 2010 at 11:00 PM, Marnen Laibow-Koser > <li...@ruby-forum.com>wrote: > >> >> If it were me, I'd use the nested_has_many_through plugin and have done >> with it. >> > > Interesting. I'll have too look into that. (This initially wasn't my > post > but still curious how to do it since I'm sure I'll run into it.) > > >> >> You could do something like car.feature_types(:joins => >> :features).collect(&:feature).uniq, though I don't know that I'd >> recommend this. You might also be able to use grouping operations on >> the DB side to do this more efficiently. >> > > Could you call car.feature_types without declaring that relationship in > some > way in the car model?
The method has to be declared somewhere, of course. I apparently messed up the one-liner: if you exchange all instances of "feature_types" and "features", you will have what I intended. > I'd have to declare feature_types as some sort of > db > relation on the car model right? (Maybe pointless anyway once I research > the > nested_has_man_through plugin?) Right. Sorry about the mixup. > > >> > >> > I'm not super comfortable with Ruby yet so I did the best I could but >> > with more of a java-esque style and am thinking it could be improved >> upon: >> >> Indeed it can. See the one-liner above. >> > > Are you referring to using the nested_has_many_through plugin or the > car.feature_types(:joins => > :features).collect(&:feature)? Yes, with the correction I made in this post. >> >> >> [...] >> > //my rspec unit tests >> >> What's with the // ? This isn't Java. >> >> > Oops sorry. Habit. Hopefully that'll change. > > >> > >> > it "should have two feature_types" do >> > car = Factory.create(:mercedes) >> > car.feature_types.size.should eq(2) >> >> Better: ...should == 2 >> > > Just curious why that is better? It's more idiomatic Ruby. You'd write x == 2, not x.eql?(2), and your matchers should follow the same practice for better readability. And I think you meant eql -- does eq even exist? > Most of the rspec matchers I was > looking at > http://rspec.rubyforge.org/rspec/1.3.0/classes/Spec/Matchers.html seem > to > refer to eq in place of == eql? and == are the same thing, at least in most classes, but I think == fits in better with the spirit of the language. > and use 'equal' for testing if it's actually > the > same object instance. Right. That's what equal? is for. Please read the docs on these three methods. > >> >> >> Try not to use factories like fixtures, which is what you're doing here. >> Specify the data as you need it. >> > > Can you please elaborate more on this? This seems contrary to my > understanding of setting up tests of your model. How so? > I bought the pragmatic > rspec book http://www.pragprog.com/titles/achbd/the-rspec-book but > haven't > had a chance to read it yet. I thought it was a good idea to use > factories > (using factory_girl) to create your isolated model objects for testing. It is. But don't create a separate factory for each car with all its features -- that's barely better than using fixtures. Instead, do Factory.create :car, :make => 'Mercedes', :feature => Factory.create(:feature, :name => 'Stereo') right in your spec file. This way you can make custom records containing exactly the properties needed for each individual spec. This ensures that each spec example only has the records it needs. It also makes it easier to use something like Faker. > It > sounds like your stating I should use the real populated DB (even if > local.) Well, factories do use the DB. What are you asking here? > I'd love some more elaboration here if you get the time. > > Thanks again for your time so far. You're welcome! Best, -- Marnen Laibow-Koser http://www.marnen.org mar...@marnen.org Sent from my iPhone -- 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 rubyonrails-t...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
