Shared state between tests

[iliabylich]

There are some weird conflicts between tests that define methods explicitly.

• All blocks passed to it are evaluated on the context of MSpec's @env
• This spec defines a method b.
• This spec relies on method b to be undefined.
• When rescue_spec runs before return_spec everything is fine.
• When return_spec runs before rescue_spec this test fails.

Should we replace all occurrences of explicitly defined methods to evaluate("def ...", &block)?

[iliabylich]

Here's a simplified example:

describe "Description" do
  evaluate <<-ruby, "Test 1" do
      def m1
        123
      end
    ruby

    m1.should == 123
  end

  it "Test 2" do
    def m2
      456
    end

    m2.should == 456
  end

  it "Test 3" do
    lambda { self.m1 }.should raise_error(NoMethodError)
    lambda { self.m2 }.should_not raise_error(NoMethodError)
  end
end

It passes because

• m1 is defined on the instance of SpecEvaluate
• m2 is defined on the shared MSpec@env

[eregon]

The environment is different per-file, isn't it?
If I run mspec language/return_spec.rb language/rescue_spec.rb with MRI I do not see an error.
In fact, I can confirm they are different objects by adding p self before those lines:

ruby 2.3.0p0 (2015-12-25 revision 53290) [x86_64-linux]
[\ |                   0%                     | 00:00:00]      0F      0E#<Object:0x00560dda563770>
[\ | ==================50%                    | 00:00:00]      0F      0E#<Object:0x00560dda641fe8>
[- | ==================100%================== | 00:00:00]      0F      0E

So, maybe an Opal bug?
Is Opal somehow using RSpec to run these, partially maybe? The semantics could differ.
Or maybe since everything is compiled ahead of time, MSpec's @env is assumed to be a fixed value?

[iliabylich]

I was testing on a single file 😄

So, maybe an Opal bug?

Yes, you are right, Opal runs all specs in the context of single object, this static object. Thanks for pointing that env is different per file!