Ginty wrote: > On May 25, 10:08�pm, Marnen Laibow-Koser <[email protected]> wrote: >> >> > No need to pass any blocks about as arguments (I really hate that, but >> > that could just be me). >> >> Er...what's wrong with blocks? �I don't get the problem, and anyway, >> they're part of idiomatic Ruby... >> > > Blocks as wrappers, iterators, etc....very nice, blocks as > arguments....meh.
Uh, no. Passing closures (blocks) as arguments is one feature that makes Ruby very powerful. You'll have to do better than "meh" to explain why you're choosing not to use a key Ruby feature, at least if you want people to take you seriously and use your software. > >> > I just never really felt in control of this from the other solutions I >> > tried (admittedly I haven't tried all of the ones on your list) and I >> > feel much happier writing tests when I know now exactly when and how >> > secondary instances are being generated. >> >> What's the point of factories that don't handle associations? �That >> seems like a huge disadvantage. �Part of the reason that I use factories >> is so I can just say Widget.make and get a fully viable Widget object, >> complete with required fields and associations. �Otherwise, why bother? >> > > Agreed not much point to that. > I didn't say that it doesn't provide any behind the scenes magic to > handle them. In your factory definition for the widgets association > you would either just call the create method for the other item, or if > you want something more elaborate (all widgets with the exact same > parent for example) your own helper method. > > Here's the example from the README for a user and an address factory, > and how you relate them. > > def user > # Define attributes via a hash, generate the values any way you want > define :name => "Jimmy", > # An 'n' counter method is available to help make things > unique Does it work with Faker? > :email => "jimmy#[email protected]", > :role => :user, > # Call your own helper methods to wire up your > associations... Does :user just get passed to a helper, or what? And what didn't you feel in control of with Machinist or Factory Girl? Machinist in particular just uses the usual Rails association mechanisms. > :address => default_address > # This would have worked also if you just want any address... > > end > > # Return a default address if it already exists, or call the address > # factory to make one > def default_address > @default_address ||= create(:address) > end > > # Alternatively loose the DSL altogether and define the factory > yourself, > # still callable via Factory.build(:address) > def address > a = Address.new > a.street = "192 Broadway" > # You can get any caller overrides via the options hash > a.city = options[:city] || "New York" > a # Only rule is the method must return the generated object > end > > end > > Anyway if you want any more info check out > http://github.com/ginty/Cranky > it's well documented. I'll check it out. Based on what you've so far said, I doubt that I'll replace Machinist with Cranky anytime soon, but I'm always open to pleasant surprises. Best, -- Marnen Laibow-Koser http://www.marnen.org [email protected] -- 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.
