On May 25, 10:51 pm, Marnen Laibow-Koser <[email protected]> wrote:
> 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.
>
>
Haha, yeah you've probably taken me down a path here I didn't really
mean to go down.
Marnen says: I didn't lead you down ...
Yeah I know.
Bottom line, this to me is ugly:
u.email {|a| "#{a.first_name}.#{[email protected]" }
this is more elegant in it's simplicity:
:email => "#{first_name}.#{[email protected]"
Personal preference.
>
>
>
> >> > 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?
Yeah it'll work with anything like that, you're just defining a
regular method, require what you will.
>
> > :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?
Good point, maybe a bad example, :user was just the value I pass to my
user.role= method. It doesn't refer to the user factory, model or
otherwise. Could equally have been :admin or what have you. I'll
change this in the docs.
>
> And what didn't you feel in control of with Machinist or Factory Girl?
> Machinist in particular just uses the usual Rails association
> mechanisms.
>
For me they are too heavy, too much magic at times (admittedly I am a
Factory Girl guy), I need to think too much about how to create an
association if I want anything other than a randomly generated one,
and ultimately I just don't like the syntax. The combination of these
things has made me feel that I've never really 'flowed' with this
aspect of writing my tests for want of a better description.
I said in the blog that Miniskirt was a real revelation to me as it
showed me that these factory helpers don't need to do much, I don't
quite understand now why some of them are so big under the hood, but
Miniskirt didn't hit the syntax aspect for me either.
So Cranky is now my factory of choice, it feels good, very good, and I
don't think that I have abnormal tastes. So I've packaged it up should
others like it to. So if you do cool, if you don't that's cool to,
we're not exactly short of choice here.
>
>
> > :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-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.
