rspec users - May 2010 - Best practices for managing fixtures outside Rails?...

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,

Stu

On May 14, 2010, at 7: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,
> 
> Stu
I''m not sure there enough people doing this sort of thing and writing
about it to have established any conventions or recommended practices.
I''d probably just follow the rails conventions here in terms of where
blueprints live, etc.

HTH,
David

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