New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Transient variables on proxy objects #103
Comments
Hey Donald, Thanks for the patch! I'll try and take a look at this soon and get back to you. Thanks, |
so, what's the status on this issue? |
I haven't had time to work on factory_girl in a while. If somebody wants to rebase the patch against master, it would be easier for me to look through. |
I'm going to close this issue since the pull request #142, which will get merged in later today, should support all the functionality requested here. Please feel free to reopen if you don't think that pull req. will handle everything. Thanks! |
Closed by c87429b |
Closes thoughtbot#142 Closes thoughtbot#103
I asked on the mailing list last week:
I recently wrote a couple of factories that could benefit from
arbitrary parameters. A sample:
https://gist.github.com/726192
Note the only difference between the two is the presence of the not
boolean operator in the latter. I'd like to DRY it up by passing in a
parameter to the factory, but the parameter in question doesn't map to
a setter method on the root object, so I can't do something like this:
Factory(:inspection_estimate, :passing => true)
At least, not without monkey patching that setter method in in the
context of the test suite, which doesn't feel right.
Can anyone suggest an alternative way of accomplishing this within
factory_girl?
Joe said:
I think something like this could be cool: https://gist.github.com/726204
If you want to put together a patch that makes it a reality, I'd be
interested.
I put together said patch:
dball@2ac4e0d
It's off of 1.3.x, since that what I use, though I'm happy to work it up against master if you're interested.
Specs are included, though I think I may have glossed over one of the code changes in the attribute subclasses, I'll run through it again tomorrow. Oh, and I just realized, I neglected to provide a spec for the Attribute::List utility class. Still, I'd love to hear your thoughts on the patch.
I don't really like the introduction of the Attribute::List decoration, but I couldn't think of a simpler way to implement the syntax Joe proposed. Alternatives include changing the behavior of Factory.method_missing to return the last attribute added, instead of the whole list, or using a Factory.ignore method to declare the transient attributes. I might also pull the duplicated code in the static and dynamic attributes up into a method on the superclass.
That said, it does the job, so take a look at let me know how you'd like me to proceed.
The text was updated successfully, but these errors were encountered: