[rspec-users] Spork

Ashley Moran
Wed, 31 Mar 2010 09:10:22 -0000

On Mar 29, 2010, at 9:04 pm, David Chelimsky wrote:

> How wide-reaching are your changes? i.e. how many files, etc?

I think it''s only really the Runner stuff that''s changed.
I''ve split it into InProcess and DRbProxy or some such... although I
think really the DRb stuff belongs higher up.


> This is an interesting catch 22. The dependency appears to be from Spork to
RSpec (i.e. RSpec doesn''t know about Spork), but RSpec needs to commit
to an API so support Spork, which is very likely the only tool that needs this
API.
>
> I wonder if we got the dep backwards? i.e. why not have Spork expose and
API and have RSpec hook into it?

Yep catch 22 indeed!  It''s a circular dependency.  The way it works is
Spork defines a DRb interface that takes arguments and the output streams.
RSpec and Cucumber are both using this the same way.  Seems like a stable
interface so this dependency isn''t a problem.

Prob is that then Spork needs to know what to do to use RSpec.  Currently that
involves (and Cucumber does the same) just passing the ARGV along.  Which felt
weird to write - because at the point you want to pass the ARGV along
you''ve already parsed it to find out if it''s a --drb run*.
But in theory you could pass anything as the args as long as the
`Rspec.my_stable_api` call accepts it.

One thought I had was that maybe the join should be separate... ie have
independent gems rspec-core and spork, and spork-rspec, spork-cucumber,
spork-testunit etc that depend on both.  The prob with this is that while Spork
is open to extension to new test frameworks, it doesn''t provide an easy
way to register them before Spork loads**.

Seems to come down to *is* Spork the only thing that would need this API?  Would
you maybe want to run specs directly in eg Redcar?  If not then I think
you''ve talked me round that the dep is backwards.  But Spork would need
refactoring for RSpec to be able provide its own Spork adapter.

Any thoughts based on that?


> If I''m wrong about this, I''d prefer to make it RSpec,
since that''s the name of the book and all :) Anybody have
insights/opinions on this?

That''s why I asked now, incase RSpec 3 changes it again and the
circular dep bites once more ;)

Cheers
Ash


* I''m not sure it''s an easy one to solve because you have to
figure out when to read in spec.opts.

** Sorta like how gem subcommands (eg gemedit) work.  I''d love to know
how that mojo does its stuff :)


--