rspec users - Aug 2009 - Class instance variable scope with multiple spec files

What is the expected/intended behavior for the scope of class instance
variables when running multiple specs?

It appears that setting a class instance variable in one spec will
affect it in a second spec run like so:

http://gist.github.com/174018

running `spec spec1_spec.rb spec2_spec.rb`  or `spec .` from within
that directory will fail because the state of the instance variable is
maintained.

I''m investigating a case where this behavior is affecting the passing/
failing of specs based on the order they are loaded by Rake''s
FileList, and am looking for a little background before I try to solve
it.

On Mon, Aug 24, 2009 at 2:19 PM, Gregory Hnatiuk<ghnatiuk at gmail.com>
wrote:
> What is the expected/intended behavior for the scope of class instance
> variables when running multiple specs?
>
> It appears that setting a class instance variable in one spec will
> affect it in a second spec run like so:
>
> http://gist.github.com/174018
>
> running `spec spec1_spec.rb spec2_spec.rb` ?or `spec .` from within
> that directory will fail because the state of the instance variable is
> maintained.
>
> I''m investigating a case where this behavior is affecting the
passing/
> failing of specs based on the order they are loaded by Rake''s
> FileList, and am looking for a little background before I try to solve
> it.
Each example is run in a separate scope, so locals and instance
variables are cleaned up by Ruby''s gc after each example.

All the examples run in one process, however, so globals are a
different matter. RSpec will clean up globals that it sets internally,
like if you stub methods on class objects, etc. Any global state
changed by the spec or the app is really up to you as the spec author
to clean up after each example.

HTH,
David
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

Thanks.
>From a best-practices perspective, should a spec which changes
something global change it back afterwards in general, or should it be
the responsibility of a given spec to ensure the environment is
appropriate itself before running examples (or both)?

It seems like changing something global in a spec and not reverting it
would be bad form, but it also seems naive to assume that prior specs
may not have changed the environment.

Greg

On Aug 24, 3:40?pm, David Chelimsky <dchelim... at gmail.com>
wrote:
> On Mon, Aug 24, 2009 at 2:19 PM, Gregory Hnatiuk<ghnat... at
gmail.com> wrote:
> > What is the expected/intended behavior for the scope of class instance
> > variables when running multiple specs?
>
> > It appears that setting a class instance variable in one spec will
> > affect it in a second spec run like so:
>
> >http://gist.github.com/174018
>
> > running `spec spec1_spec.rb spec2_spec.rb` ?or `spec .` from within
> > that directory will fail because the state of the instance variable is
> > maintained.
>
> > I''m investigating a case where this behavior is affecting the
passing/
> > failing of specs based on the order they are loaded by Rake''s
> > FileList, and am looking for a little background before I try to solve
> > it.
>
> Each example is run in a separate scope, so locals and instance
> variables are cleaned up by Ruby''s gc after each example.
>
> All the examples run in one process, however, so globals are a
> different matter. RSpec will clean up globals that it sets internally,
> like if you stub methods on class objects, etc. Any global state
> changed by the spec or the app is really up to you as the spec author
> to clean up after each example.
>
> HTH,
> David
>
> > _______________________________________________
> > rspec-users mailing list
> > rspec-us... at rubyforge.org
> >http://rubyforge.org/mailman/listinfo/rspec-users
>
> _______________________________________________
> rspec-users mailing list
> rspec-us... at
rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users

On 24 Aug 2009, at 22:00, Gregory Hnatiuk wrote:
> Thanks.
>
>> From a best-practices perspective, should a spec which changes
> something global change it back afterwards in general, or should it be
> the responsibility of a given spec to ensure the environment is
> appropriate itself before running examples (or both)?
>
> It seems like changing something global in a spec and not reverting it
> would be bad form, but it also seems naive to assume that prior specs
> may not have changed the environment.
I always try to put things back as I found them. For example:

before(:all) do
   @original_thread_abort_on_exception = Thread.abort_on_exception
   Thread.abort_on_exception = true
end

after(:all) do
   Thread.abort_on_exception = @original_thread_abort_on_exception
end

Actually, I wonder what happens with these instance variables in  
before/after all blocks given what David just said. Do I get the  
behaviour I''d expect?
>
> Greg
>
> On Aug 24, 3:40 pm, David Chelimsky <dchelim... at gmail.com> wrote:
>> On Mon, Aug 24, 2009 at 2:19 PM, Gregory  
>> Hnatiuk<ghnat... at gmail.com> wrote:
>>> What is the expected/intended behavior for the scope of class  
>>> instance
>>> variables when running multiple specs?
>>
>>> It appears that setting a class instance variable in one spec will
>>> affect it in a second spec run like so:
>>
>>> http://gist.github.com/174018
>>
>>> running `spec spec1_spec.rb spec2_spec.rb`  or `spec .` from within
>>> that directory will fail because the state of the instance  
>>> variable is
>>> maintained.
>>
>>> I''m investigating a case where this behavior is affecting
the
>>> passing/
>>> failing of specs based on the order they are loaded by
Rake''s
>>> FileList, and am looking for a little background before I try to  
>>> solve
>>> it.
>>
>> Each example is run in a separate scope, so locals and instance
>> variables are cleaned up by Ruby''s gc after each example.
>>
>> All the examples run in one process, however, so globals are a
>> different matter. RSpec will clean up globals that it sets  
>> internally,
>> like if you stub methods on class objects, etc. Any global state
>> changed by the spec or the app is really up to you as the spec author
>> to clean up after each example.
>>
>> HTH,
>> David
>>
>>> _______________________________________________
>>> rspec-users mailing list
>>> rspec-us... at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
>> _______________________________________________
>> rspec-users mailing list
>> rspec-us... at
rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users