Andrew,
On Thu, Jul 8, 2010 at 7:47 AM, Andrew Premdas <aprem...@gmail.com> wrote:
>
>
> On 8 July 2010 11:46, David Chelimsky <dchelim...@gmail.com> wrote:
>>
>> On Jul 8, 2010, at 4:24 AM, Andrew Premdas wrote:
>>
>> On 8 July 2010 01:01, David Chelimsky <dchelim...@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
>
> 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:
http://gist.github.com/511874
Best regards,
Michael Guterl
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
