Hello I have seen that some people in this list is using Fixjour as the replacement of fixtures. But I can''t understand why it is superior or better than other approaches to the subject like Machinist o FactoryGirl. What are the problems this library resolve? Can somebody explain this a little. Thank you. Juanma -- Posted via http://www.ruby-forum.com/.
I''m sorry for the question. I have just seen that this question is already treated in a very near thread. I didn''t see it. Juanma -- Posted via http://www.ruby-forum.com/.
Juanma Cervera wrote:> Hello > I have seen that some people in this list is using Fixjour as the > replacement of fixtures. > But I can''t understand why it is superior or better than other > approaches to the subject like Machinist o FactoryGirl. > What are the problems this library resolve? > > Can somebody explain this a little. >Excuse the rant, but I need to go to bed before I wake up in 2 hours: I think part of it is that the other plugins all have an interface that sort of makes you want to throw up in your mouth. Or at least, they do for me. The only two interfaces that I''ve understood are FixtureReplacements and Fixjour, and they happen to generate the same methods. I asked Pat exactly what he thought it provided over FixtureReplacement. Here were his exact words: "So my main objective with fixjour is to have the simplest implementation possible, with a very simple API. So it will create the following methods: new_[model], create_[model], and valid_[model]_attributes." The interface isn''t much different from FRs on a day to day basis. FR provides a ton more but its internal implementation is shit and very un-hackable. I don''t know anything about Machinist. Factory girl was written because of a misconception with FixtureReplacement (the author thought that it didn''t allow lambdas for associations - which is my own fault, because the api probably sucked). He also thought that it that relied to heavily on random values (although, I have no idea on how to provide good defaults - and I don''t think that FG has solved that issue, either). Put the ThoughtBot machine in full drive, and it''s not hard to get recognition (it also doesn''t hurt to have like 30 rails developers at your company who probably all adopt it at the same time - that''s like 1/3 of rubyconf). I''m not taking anything away from the plugin - it looks relatively clean, and I''m sure the internals are OK. Object Daddy was developed at about the same time as FR, and as far as I know, also originated from this Dan Manges post: http://www.dcmanges.com/blog/38 IMHO, I don''t like the idea of defining test data in the model, and I don''t like the necessarily tight coupling of one class => one fixture. Usually thats a good bet, but we all have "edge" cases. Once in a while an "Admin" won''t be it''s own class, it''ll be a boolean field on the User. Does this mean that I now should need to pass :admin => true for every test case against a user? Couldn''t I just say "create_admin" instead of create_user(:admin => true)? There are a ton of subtle details to each of them (like: do they support attr_protected attributes, lambdas for wrapping the association when defining it, inheriting default fixtures, model namespacing, automatically merging attributes, creating custom named fixtures (for those times you want admin_user but don''t have an Admin model), etc. etc.). Creating a matrix of these things and seeing which plugins implement which would be interesting. Ultimately, I guess it comes down to the API, and what feels correct and clean. All of these do basically the same thing at the core, but they can all be abused to create terrible specs. That''s my .02 on the matter, Scott> Thank you. > Juanma >
Scott Taylor wrote: > [> "So my main objective with fixjour is to have the simplest > implementation possible, with a very simple API. So it will create the > following methods: new_[model], create_[model], and > valid_[model]_attributes."This seems to be an anti-pattern in the Rails community: "I can''t follow Library X, so I''ll write Library Y, which is lightweight and obeys YAGNI, and is the simplest possible implementation." I confess: I''ve done it too. But it''s nearly always the wrong approach. If you can''t follow Library X''s *implementation*, but you agree with its *philosophies*, refactor it! Competing libraries should have different goals, different purposes, different anything other than just "cleaner code". If Merb can refactor itself into Rails, you can do it with fixtures, authentication, file attachments, or what have you. As easy as Github makes forking, the choice of libraries should no longer be driven by "this one was updated most recently" or "this one uses the most recent design idioms". As someone wrote recently: The minute you start coding, you''re writing legacy code. Jay Levitt
Well sometimes one can''t use an existing library becuase of some reason or other, like in my case not using ActiveRecord. So I came up with yet another way to do it, I think it is a hyvrid between Fixtures and Factories. outlined here... http://blog.wolfman.com/posts/42 On Feb 7, 8:16?am, Jay Levitt <lists-rs... at shopwatch.org> wrote:> Scott Taylor wrote: > > ?> [ > > > "So my main objective with fixjour is to have the simplest > > implementation possible, with a very simple API. So it will create the > > following methods: new_[model], create_[model], and > > valid_[model]_attributes." > > This seems to be an anti-pattern in the Rails community: > > "I can''t follow Library X, so I''ll write Library Y, which is lightweight and > obeys YAGNI, and is the simplest possible implementation." > > I confess: I''ve done it too. ?But it''s nearly always the wrong approach. ?If > you can''t follow Library X''s *implementation*, but you agree with its > *philosophies*, refactor it! > > Competing libraries should have different goals, different purposes, > different anything other than just "cleaner code". ?If Merb can refactor > itself into Rails, you can do it with fixtures, authentication, file > attachments, or what have you. ?As easy as Github makes forking, the choice > of libraries should no longer be driven by "this one was updated most > recently" or "this one uses the most recent design idioms". > > As someone wrote recently: The minute you start coding, you''re writing > legacy code. > > Jay Levitt > > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users
I started writing up a response about why I wrote Fixjour, and why I want it to be its own project, but it got really long. Here''s a Markdownified gist: http://gist.github.com/60389. For the record, I think FR is a great tool (I link to it in Fixjour''s README), it''s just not for me. Read the gist above and you''ll be able to see why. Pat On Feb 7, 9:36?pm, Jim Morris <wolfma... at gmail.com> wrote:> Well sometimes one can''t use an existing ?library becuase of some > reason or other, like in my case not using ActiveRecord. > > So I came up with yet another way to do it, I think it is a hyvrid > between Fixtures and Factories. > > outlined here... > > http://blog.wolfman.com/posts/42 > > On Feb 7, 8:16?am, Jay Levitt <lists-rs... at shopwatch.org> wrote: > > > Scott Taylor wrote: > > > ?> [ > > > > "So my main objective with fixjour is to have the simplest > > > implementation possible, with a very simple API. So it will create the > > > following methods: new_[model], create_[model], and > > > valid_[model]_attributes." > > > This seems to be an anti-pattern in the Rails community: > > > "I can''t follow Library X, so I''ll write Library Y, which is lightweight and > > obeys YAGNI, and is the simplest possible implementation." > > > I confess: I''ve done it too. ?But it''s nearly always the wrong approach. ?If > > you can''t follow Library X''s *implementation*, but you agree with its > > *philosophies*, refactor it! > > > Competing libraries should have different goals, different purposes, > > different anything other than just "cleaner code". ?If Merb can refactor > > itself into Rails, you can do it with fixtures, authentication, file > > attachments, or what have you. ?As easy as Github makes forking, the choice > > of libraries should no longer be driven by "this one was updated most > > recently" or "this one uses the most recent design idioms". > > > As someone wrote recently: The minute you start coding, you''re writing > > legacy code. > > > Jay Levitt > > > _______________________________________________ > > rspec-users mailing list > > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users
Pat Nakajima wrote:> I started writing up a response about why I wrote Fixjour, and why I > want it to be its own project, but it got really long. Here''s a > Markdownified gist: http://gist.github.com/60389. > > For the record, I think FR is a great tool (I link to it in Fixjour''s > README), it''s just not for me. Read the gist above and you''ll be able > to see why. > > Pat >+1 Nice post, Pat. I think this post belongs somewhere on the c2 wiki. Although, I still disagree with the create_admin example. Here''s a rundown of the different syntaxes: http://gist.github.com/60497 I''d prefer to have the flexibility there. In FR you *could* use create_user(:admin => true) every time, which works well when that''s the only attribute given. When extra attributes are needed as well, I think the test can become too busy. But I do think you are on point with this comment: "If I did feel the need for a create_admin helper, it might be a sign that I need an Admin model." I''m not opposed to named fixtures per-se, I''m opposed to named fixtures where the *intent* of the spec becomes obfuscated by the attributes. So why does user_joana_who_has_19_outstand_mortgage_payments also have an invalid email address? Who knows. But with create_admin(:other_flag => true) the meaning of the spec is probably going to be clear, even if the internal implementation isn''t. And ultimately, my idea behind a good spec doesn''t reveal an internal implementation (black box testing has always been more of my forte) . I''m less gung ho about supporting attr_protected. I can see it going both ways. Thanks for the interesting post, Scott> On Feb 7, 9:36 pm, Jim Morris <wolfma... at gmail.com> wrote: > >> Well sometimes one can''t use an existing library becuase of some >> reason or other, like in my case not using ActiveRecord. >> >> So I came up with yet another way to do it, I think it is a hyvrid >> between Fixtures and Factories. >> >> outlined here... >> >> http://blog.wolfman.com/posts/42 >> >> On Feb 7, 8:16 am, Jay Levitt <lists-rs... at shopwatch.org> wrote: >> >> >>> Scott Taylor wrote: >>> >>> > [ >>> >>>> "So my main objective with fixjour is to have the simplest >>>> implementation possible, with a very simple API. So it will create the >>>> following methods: new_[model], create_[model], and >>>> valid_[model]_attributes." >>>> >>> This seems to be an anti-pattern in the Rails community: >>> >>> "I can''t follow Library X, so I''ll write Library Y, which is lightweight and >>> obeys YAGNI, and is the simplest possible implementation." >>> >>> I confess: I''ve done it too. But it''s nearly always the wrong approach. If >>> you can''t follow Library X''s *implementation*, but you agree with its >>> *philosophies*, refactor it! >>> >>> Competing libraries should have different goals, different purposes, >>> different anything other than just "cleaner code". If Merb can refactor >>> itself into Rails, you can do it with fixtures, authentication, file >>> attachments, or what have you. As easy as Github makes forking, the choice >>> of libraries should no longer be driven by "this one was updated most >>> recently" or "this one uses the most recent design idioms". >>> >>> As someone wrote recently: The minute you start coding, you''re writing >>> legacy code. >>> >>> Jay Levitt >>> >>> _______________________________________________ >>> rspec-users mailing list >>> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users >>> >> _______________________________________________ >> rspec-users mailing list >> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users >> > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
I think that named fixtures are primarily a matter of taste. With that being said, I did want to explain mine a bit.> When extra attributes are needed as well, I think the test can become too > busy. >A lot of time, I feel like processing the overrides hash is just a bandaid over something missing from the actual object model. Creating named fixtures is essentially the composition of these patches, which can lead to obfuscating object creation methods that evolve to mask smells in the real code (If I sound a bit dramatic, it''s because I was recently on a "perfect storm" project where this happened). I know it''s not really feasible to do everything through extra attributes though. I just prefer defining "scenario" methods elsewhere, that are totally detached from the builders, which should be as isolated as possible.> So why does user_joana_who_has_19_outstand_mortgage_payments also have an > invalid email address? Who knows.Totally. That''s the kind of setup we were working with before deciding to rip it out. I''m less gung ho about supporting attr_protected. I can see it going both> ways.Today I was working on a side project and the abundance of attr_protected fields really started to stick in my crawl, so I started toying with a way to make it easier to create builders that integrate these fields without losing the fact that they are in fact special. The result is in a branch ( http://github.com/nakajima/fixjour/tree/protected-attributes) until I can figure out whether I like it or not, but the gist is this: define_builder(Person) do |klass, overrides| klass.protected :purchases klass.new :purchases => 0, :email => "foo at blah.com" end The protected fields can then be declared and passed to the creation methods like they were any other method, but we still get to see the fact that they''re protected. I''d love to get some feedback on this style, as I''m a bit on the fence about it. Not such much because #protected means other things in Ruby, but because I''m not sure if it should be more explicit. Pat On Sun, Feb 8, 2009 at 3:44 PM, Scott Taylor <scott at railsnewbie.com> wrote:> Pat Nakajima wrote: >> >> I started writing up a response about why I wrote Fixjour, and why I >> want it to be its own project, but it got really long. Here''s a >> Markdownified gist: http://gist.github.com/60389. >> >> For the record, I think FR is a great tool (I link to it in Fixjour''s >> README), it''s just not for me. Read the gist above and you''ll be able >> to see why. >> >> Pat >> > > +1 > > Nice post, Pat. I think this post belongs somewhere on the c2 wiki. > > Although, I still disagree with the create_admin example. Here''s arundown> of the different syntaxes: > > http://gist.github.com/60497 > > I''d prefer to have the flexibility there. In FR you *could* use > create_user(:admin => true) every time, which works well when that''s the > only attribute given. When extra attributes are needed as well, I thinkthe> test can become too busy. But I do think you are on point with this > comment: > > "If I did feel the need for a create_admin helper, it might be a signthat> I need an Admin model." > > I''m not opposed to named fixtures per-se, I''m opposed to named fixtures > where the *intent* of the spec becomes obfuscated by the attributes. Sowhy> does user_joana_who_has_19_outstand_mortgage_payments also have an invalid > email address? Who knows. But with create_admin(:other_flag => true)the> meaning of the spec is probably going to be clear, even if the internal > implementation isn''t. And ultimately, my idea behind a good spec doesn''t > reveal an internal implementation (black box testing has always been moreof> my forte) . > > I''m less gung ho about supporting attr_protected. I can see it going both > ways. > > Thanks for the interesting post, > > Scott > > > > > > > > > >> On Feb 7, 9:36 pm, Jim Morris <wolfma... at gmail.com> wrote: >> >>> >>> Well sometimes one can''t use an existing library becuase of some >>> reason or other, like in my case not using ActiveRecord. >>> >>> So I came up with yet another way to do it, I think it is a hyvrid >>> between Fixtures and Factories. >>> >>> outlined here... >>> >>> http://blog.wolfman.com/posts/42 >>> >>> On Feb 7, 8:16 am, Jay Levitt <lists-rs... at shopwatch.org> wrote: >>> >>> >>>> >>>> Scott Taylor wrote: >>>> > [ >>>> >>>>> >>>>> "So my main objective with fixjour is to have the simplest >>>>> implementation possible, with a very simple API. So it will create the >>>>> following methods: new_[model], create_[model], and >>>>> valid_[model]_attributes." >>>>> >>>> >>>> This seems to be an anti-pattern in the Rails community: >>>> "I can''t follow Library X, so I''ll write Library Y, which is >>>> lightweight and >>>> obeys YAGNI, and is the simplest possible implementation." >>>> I confess: I''ve done it too. But it''s nearly always the wrong >>>> approach. If >>>> you can''t follow Library X''s *implementation*, but you agree with its >>>> *philosophies*, refactor it! >>>> Competing libraries should have different goals, different >>>> purposes, >>>> different anything other than just "cleaner code". If Merb canrefactor>>>> itself into Rails, you can do it with fixtures, authentication, file >>>> attachments, or what have you. As easy as Github makes forking, the >>>> choice >>>> of libraries should no longer be driven by "this one was updated most >>>> recently" or "this one uses the most recent design idioms". >>>> As someone wrote recently: The minute you start coding, you''re >>>> writing >>>> legacy code. >>>> Jay Levitt >>>> _______________________________________________ >>>> rspec-users mailing list >>>> >>>> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users>>>> >>> >>> _______________________________________________ >>> rspec-users mailing list >>> >>> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users>>> >> >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >> > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20090208/03814743/attachment.html>