-
-
Save hovsater/6213677 to your computer and use it in GitHub Desktop.
| Seeda.definitions do | |
| # A simple seed | |
| seed { Category.create! name: "Example Category" } | |
| # Seeds can be defined in groups | |
| define :users do | |
| # Seeds can be named for later reference | |
| seed(:john) { User.create! name: "John Doe" } | |
| seed(:jane) { User.create! name: "Jane Doe" } | |
| end | |
| # Seeds can have dependencies | |
| define :posts, [:users] do |users| | |
| seed { users(:john).posts.create! title: "A post" } | |
| seed { users(:jane).posts.create! title: "Another post" } | |
| end | |
| end |
@jgaskins I feel the same way. I do love the magic that class_exec and instance_exec provide, but I don't think it's worth it if people having a hard time understanding what context the methods are executed in. At first thought, I don't think the magic happening here is too confusing, but on the other hand, a new user to gem might think so.
I guess it's a decision that have to be made on whether to use yield or class_exec and instance_exec.
One thought that popped into mind was to convert the name of the definition into singular and then use it like so: seed { user.create! foo: bar } but I think that is too much trouble of converting the name into singular as well as the confusion with the seed syntax that takes an argument.
@dbrady I will definitely look into FixJour and see if I can get some inspiration!
I don't have much to add other than I like the direction you're heading. There was a WONDERFUL baby that got thrown out with the bathwater called FixJour a few years ago. The thing I liked about it was that you could build complicated nested objects by default, E.g.
build :userwould return aUserwith an associated defaultProfile, but if you specified a profile object in the build call, it would seamlessly override the default. This let you do things like spec a user with a nil/missing profile just by callingbuild :user, profile: nil, etc.Anyway, my point is you might want to look at FJ, but if not, please do consider making it easy to override seeds from the test suite UNLESS OF COURSE that's sort of not your point in creating Seeda in the first place. :-)