[rspec-users] RSpec uses at_exit - forks and stuff

23 views
Skip to first unread message

Andrew Premdas

unread,
Jul 7, 2010, 9:22:38 AM7/7/10
to rspec-users
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

David Chelimsky

unread,
Jul 7, 2010, 8:01:48 PM7/7/10
to rspec-users
On Jul 7, 2010, at 8:22 AM, Andrew Premdas 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

>
> TIA
>
> Andrew
> _______________________________________________
> rspec-users mailing list
> rspec...@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

_______________________________________________
rspec-users mailing list
rspec...@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Andrew Premdas

unread,
Jul 8, 2010, 5:24:03 AM7/8/10
to rspec-users
On 8 July 2010 01:01, David Chelimsky <dchel...@gmail.com> wrote:
On Jul 7, 2010, at 8:22 AM, Andrew Premdas 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

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

David Chelimsky

unread,
Jul 8, 2010, 6:46:54 AM7/8/10
to rspec-users
On Jul 8, 2010, at 4:24 AM, Andrew Premdas wrote:
On 8 July 2010 01:01, David Chelimsky <dchel...@gmail.com> wrote:
On Jul 7, 2010, at 8:22 AM, Andrew Premdas 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

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 http://github.com/rsanheim/rspec-rails23, 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

Andrew Premdas

unread,
Jul 8, 2010, 7:47:50 AM7/8/10
to rspec-users
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

Michael Guterl

unread,
Aug 6, 2010, 3:44:10 PM8/6/10
to rspec-users, apre...@gmail.com
Andrew,

While I came up with my own solution to this problem, I would love to
compare solutions. Here's what I came up with:
http://gist.github.com/511874

Best regards,
Michael Guterl

Reply all
Reply to author
Forward
0 new messages