This issue came up a while ago: GH-26. I think the root problem is about mismatched expectations.

Since Speclj is based on RSpec, I assumed that it components worked just like RSpec; when they are run they attach themselves to their current context. For example, this works in RSpec:

describe "it blocks" do

  def self.run_me
    it "runs this test" do
      1.should == 2
    end

    it "and it runs this test" do
      2.should == 1
    end
  end

  run_me
end

$ rspec it_spec.rb
FF

Failures:

  1) it blocks runs this test
     Failure/Error: 1.should == 2
       expected: 2
            got: 1 (using ==)
     # ./it_spec.rb:7:in `block in run_me'

  2) it blocks and it runs this test
     Failure/Error: 2.should == 1
       expected: 1
            got: 2 (using ==)
     # ./it_spec.rb:11:in `block in run_me'

Finished in 0.00088 seconds
2 examples, 2 failures

Failed examples:

rspec ./it_spec.rb:6 # it blocks runs this test
rspec ./it_spec.rb:10 # it blocks and it runs this test

However, Speclj differs. it components do not attach themselves to the current context. Instead, describe components will attach any components that are passed to it. So, in @skatenerd 's example, only the last example is passed to the describe block; resulting in a test that never runs.

from speclj.

Right. A Context (describe block) is a collection of Examples (it blocks). So when your test code is evaluated, Speclj collects a sequence of Contexts, which in turn collect a sequence of Examples; but none of the tests are “Executed” yet. This is good for a couple reasons.

1. It fits the functional paradigm. Executing the tests generates side effects. Speclj postpones that as long as possible.
2. The tests can be re-run. They’re just a bunch of functions stored in an persistent collection. Custom Runners can take advantage of this fact like the Vigilant (auto) runner does.

Knowing this, the use of ‘let’ should seem suspicious. Because the bindings are only valid when the specs are evaluated. You may not get what you want at execution time. Speclj provides components that you’ll prefer to use (‘with’ ‘before’ ‘after’ …)

That said, it is often useful to use a ‘for’ form to generate multiple examples. So long as your specs are wrapped in a list, which is what the ‘for’ form does, Speclj will flatten the nested structure.

On Jan 22, 2014, at 9:22 AM, Myles Megyesi [email protected] wrote:

This issue came up a while ago: GH-26. I think the root problem is about mismatched expectations.

Since Speclj is based on RSpec, I assumed that it components worked just like RSpec; when they are run they attach themselves to their current context. For example, this works in RSpec:

describe "it blocks" do

def self.run_me
it "runs this test" do
1.should == 2
end

it "and it runs this test" do
  2.should == 1
end

end

run_me
end
$ rspec it_spec.rb
FF

Failures:

1. it blocks runs this test
   Failure/Error: 1.should == 2
   expected: 2
   got: 1 (using ==)

   ./it_spec.rb:7:in `block in run_me'

2. it blocks and it runs this test
   Failure/Error: 2.should == 1
   expected: 1
   got: 2 (using ==)

   ./it_spec.rb:11:in `block in run_me'

Finished in 0.00088 seconds
2 examples, 2 failures

Failed examples:

rspec ./it_spec.rb:6 # it blocks runs this test
rspec ./it_spec.rb:10 # it blocks and it runs this test
However, Speclj differs. it components do not attach themselves to the current context. Instead, describe components will attach any components that are passed to it. So, in @skatenerd 's example, only the last example is passed to the describe block; resulting in a test that never runs.

—
Reply to this email directly or view it on GitHub.

from speclj.