RSpec uses at_exit - forks and stuff

Testing RSpec
1

Hi there.

My understanding (which is limited) is that rspec uses at_exit to run
its
specs. I don’t really know why - could somoene explain?

My problem with this behaviour is that I would like the running of a
spec to
start an instance of solr (using Sunspot) if one is not running. The
problem
with this is that Sunspot forks to start solr, and when these forks exit
they run my specs. At best this causes specs to be run more than once,
at
worst it causes specs to fail in their hundreds.

I can fix this by adding an at_exit for each fork …

fork do
  ...
  at_exit { exit! }
end

but this means changing the Sunspot code, which I really shouldn’t have
to
do to run specs. So is their anything else I can do. Ideally in
spec_helper
or another rspec support file.

TIA

Andrew

2

On Jul 7, 2010, at 8:22 AM, Andrew P. wrote:

Hi there.

My understanding (which is limited) is that rspec uses at_exit to run its specs. I don’t really know why - could somoene explain?

The initial motivation was that it makes it easy to make sure it works
whether you run it with the ruby command or the rspec command. Over the
years it has caused some trouble though, so I’d be interested in a
different solution.

My problem with this behaviour is that I would like the running of a spec to start an instance of solr (using Sunspot) if one is not running. The problem with this is that Sunspot forks to start solr, and when these forks exit they run my specs. At best this causes specs to be run more than once, at worst it causes specs to fail in their hundreds.

I can fix this by adding an at_exit for each fork …

fork do
  ...
  at_exit { exit! }    
end

but this means changing the Sunspot code, which I really shouldn’t have to do to run specs. So is their anything else I can do. Ideally in spec_helper or another rspec support file.

I added RSpec::Core::Runner.disable_autorun! to beta.16 in order to
solve a similar problem. No guarantees it will stay there if I come up
with a better way to deal with supporting multiple entry points, but if
I remove it I’ll formally deprecate it (so you’re safe to use it).

HTH,
David

3

On 8 July 2010 01:01, David C. [email protected] wrote:

solution.

  ...

formally deprecate it (so you’re safe to use it).

HTH,
David

Thanks for your reply David. Does this only apply only to rspec2? (the beta
16 seems a bit of a giveaway). Is there something I can do with rspec
1x.
I’ve tried commenting out require ‘spec/autorun’, but that had no
effect.
Is there is something I could do like put a monkey patch in spec helper.

On a related note, can rspec 2 be used on rails 2x projects

All best

Andrew

4

On 8 July 2010 11:46, David C. [email protected] wrote:

I’ve tried commenting out require ‘spec/autorun’, but that had no effect.
NOT to be the basis for an official rspec2-rails2 gem so please don’t use
this expecting a smooth upgrade path once such a gem exists.

HTH,
David

Thanks for your input David, current fix is to monkey patch the
offending
code and add at_exit { exit! } to the end of each fork block. Not
pretty,
but it will do for now. Clearly we will have to bite the bullet and go
to
rails3 rspec2 at some point, struggling to keep up with the pace of
change
at the moment.

All best

Andrew

5

Andrew,

On Thu, Jul 8, 2010 at 7:47 AM, Andrew P. [email protected]
wrote:

Hi there.
spec to start an instance of solr (using Sunspot) if one is not running. The

David
look at merging it.
this expecting a smooth upgrade path once such a gem exists.
HTH,
David

Thanks for your input David, current fix is to monkey patch the offending
code and add  at_exit { exit! } to the end of each fork block. Not pretty,
but it will do for now. Clearly we will have to bite the bullet and go to
rails3 rspec2 at some point, struggling to keep up with the pace of change
at the moment.

While I came up with my own solution to this problem, I would love to
compare solutions. Here’s what I came up with:

Best regards,
Michael G.

6

On Jul 8, 2010, at 4:24 AM, Andrew P. wrote:

HTH,
David

Thanks for your reply David. Does this only apply only to rspec2?

Yes.

(the beta 16 seems a bit of a giveaway). Is there something I can do with rspec 1x.

Not sure, but I really don’t have time to experiment with this right now

  • sorry. If you do, and come up with something, please post it back and
    I’ll look at merging it.

I’ve tried commenting out require ‘spec/autorun’, but that had no effect. Is there is something I could do like put a monkey patch in spec helper.

On a related note, can rspec 2 be used on rails 2x projects

Not quite yet. Definitely in the plan, but probably not going to happen
until the fall unless someone other than me makes it so.

There is GitHub - rsanheim/rspec-rails23: Rspec2 for Rails 2.3.5 - archived and unsupported, which works with a
subset of rspec-rails-2 functionality and only up to beta.8. This is
likely NOT to be the basis for an official rspec2-rails2 gem so please
don’t use this expecting a smooth upgrade path once such a gem exists.

HTH,
David