On May 14, 2010, at 8:25 PM, Stu wrote: > Hi, > > I have a non-Rails Ruby project that uses RSpec. It needs a shared > collection of fixture-like objects created, although they have nothing > to do with Rails, AR or database entries: > > w1 = Widget.new(10) > w2 = Widget.new(20) > w3 = Widget.new(30) > # ... > > g1 = Gadget.new(w1, w2) > g2 = Gadget.new(w3, w1) > g3 = Gadget.new(w2, w3) > #... > > Currently these are in a shared examples.rb file and are brought into > various *_spec.rb files in a way that feels like a real hack. I've > since discovered a fork of Machinist that works with PORO's and allows > those object to have an initializer with arguments, so I should be > able to replace the above with machinist blueprints etc. > > I figure I'm not the first person in the world to be using RSpec and > fixture-like objects in this way, so are there any best practices for > doing this outside Rails? I've read this a number of times, but it's > starting to sink in that projects need to manage their specs/tests > with the same agility and care they devote to the code. > > Any advice much appreciated,
I've always used FixtureReplacement in place of fixtures, which clears up my spec/fixtures directory. Often on rails projects I'll have spec/fixtures/mailers, and possibly other random files in spec/fixtures, scaling up the organization as necessary. Any of the ruby files I'll require from the spec_helper. Regards, Scott _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
