On May 25, 10:08 pm, Marnen Laibow-Koser <[email protected]> wrote:
> Ginty wrote:
> > There are many factories, but this one is mine.....admittedly that
> > could be it to some extent!
>
> > To me the benefits are:
>
> > It is extremely light, which means it ain't gonna break on you when
> > other components of your test environment change.
>
> That sounds good.
>
> > 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.
>
>
> > The syntax could not be simpler and less obtrusive.
>
> Great!
>
>
>
> > It doesn't provide any magic for dealing with associations, you're own
> > your own. This was probably the #1 reason I developed this for myself,
> > 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
:email => "jimmy#[email protected]",
:role => :user,
# Call your own helper methods to wire up your
associations...
: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.
> Best,
> --
> Marnen Laibow-Koserhttp://www.marnen.org
> [email protected]
>
> --
> Posted viahttp://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.
