Muki-SkyWalker / specs

Automatically exported from code.google.com/p/specs
Other
0 stars 0 forks source link

running a sequential specification with NotifierRunner does not execute in isolation #106

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
There is a subtle isolation issue with sequential specs when run with a
notifierrunner. It seems that not all initialization of the systems are
done correctly. For example the following spec can be run succesfully with
the standard OutputReporter, but when run with a NotifierRunner, the first
examples of the systems will fail.

object FooSpecs extends Specification{
  var specFoo: Object = new Object
  "Foo" should{
    setSequential()
    val susFoo = new Object
    specFoo = susFoo
    "execute in isolation" in{
      specFoo mustBe susFoo
    }
    "execute in isolation 2" in{
      specFoo mustBe susFoo
    }
  }
  "Bar" should{
    val susFoo = new Object
    specFoo = susFoo
    "execute in isolation" in{
      specFoo mustBe susFoo
    }
    "execute in isolation 2" in{
      specFoo mustBe susFoo
    }
  }
}

Sorry about this recent 'harassing' with the issues.. :) 

Original issue reported on code.google.com by saynomoo@gmail.com on 5 Jan 2010 at 2:25

GoogleCodeExporter commented 9 years ago

Original comment by etorrebo...@gmail.com on 7 Jan 2010 at 7:38

GoogleCodeExporter commented 9 years ago
This issue was closed by revision r1204.

Original comment by etorrebo...@gmail.com on 7 Jan 2010 at 11:04

GoogleCodeExporter commented 9 years ago
Can you please check that issue 106 is solved with the latest snapshot?

> Sorry about this recent 'harassing' with the issues.. :)

Please do! I'd rather not have too many weird bugs around.

Original comment by etorrebo...@gmail.com on 7 Jan 2010 at 11:06

GoogleCodeExporter commented 9 years ago
This issue is also fixed by the latest snapshot. thx again!

Original comment by saynomoo@gmail.com on 7 Jan 2010 at 1:14

GoogleCodeExporter commented 9 years ago
There still seems to be some problem with the latest snapshot after all. There 
can
currently be only two examples in a system if the spec is sequential. For 
example in
the following spec: 

object FooSpecs extends Specification{
  var specFoo: Object = new Object
  "Foo" should{
    setSequential()
    val susFoo = new Object
    specFoo = susFoo
    "execute in isolation" in{
      specFoo mustBe susFoo
    }
    "execute in isolation 2" in{
      specFoo mustBe susFoo
    }
    "execute in isolation 3" in{
      specFoo mustBe susFoo
    }
  }
  "Bar" should{
    val susFoo = new Object
    specFoo = susFoo
    "execute in isolation" in{
      specFoo mustBe susFoo
    }
    "execute in isolation 2" in{
      specFoo mustBe susFoo
    }
  }
}

the "execute in isolation 3" example won't get created.

Original comment by saynomoo@gmail.com on 7 Jan 2010 at 3:13

GoogleCodeExporter commented 9 years ago
Sorry about that. The interaction between setSequential and having no shared 
variables 
(which means cloning the specification to execute examples in isolation are 
indeed 
tricky to get right)

Original comment by etorrebo...@gmail.com on 7 Jan 2010 at 10:10

GoogleCodeExporter commented 9 years ago
New try. Please have a go at it. Thanks.

Original comment by etorrebo...@gmail.com on 8 Jan 2010 at 12:49

GoogleCodeExporter commented 9 years ago
Unfortunately the fix did not work. Now the first examples of all systems but 
the
first will not be run in isolation. For example in the following spec:

object FooSpecs extends Specification{
  setSequential()
  var specFoo: Object = new Object
  "Foo" should{
    val susFoo = new Object
    specFoo = susFoo
    "execute in isolation" in{
      specFoo mustBe susFoo
    }
    "execute in isolation 2" in{
      specFoo mustBe susFoo
    }
    "execute in isolation 3" in{
      specFoo mustBe susFoo
    }
  }
  "Bar" should{
    val susFoo = new Object
    specFoo = susFoo
    "execute in isolation" in{
      specFoo mustBe susFoo
    }
    "execute in isolation 2" in{
      specFoo mustBe susFoo
    }
    "execute in isolation 3" in{
      specFoo mustBe susFoo
    }
  }
  "Baz" should{
    val susFoo = new Object
    specFoo = susFoo
    "execute in isolation" in{
      specFoo mustBe susFoo
    }
    "execute in isolation 2" in{
      specFoo mustBe susFoo
    }
    "execute in isolation 3" in{
      specFoo mustBe susFoo
    }
  }
}

Both Bar's and Baz's first example will fail.

Original comment by saynomoo@gmail.com on 8 Jan 2010 at 1:04

GoogleCodeExporter commented 9 years ago
It looks like this is an initialization issue. If I declare FooSpecs as a class 
and I 
use a notifier like:

object notifiedFooSpecs extends NotifierRunner(new FooSpecs, new 
ConsoleNotifier)

Then I don't have any issue.

You can try with this simplified version of FooSpecs which does the trick:

class FooSpecs extends Specification{
  setSequential()
  var specFoo: Object = new Object
  "sus1" should{
    val susFoo = new Object
    specFoo = susFoo
    "execute in isolation 1-1" in{
      specFoo mustBe susFoo
    }
    "execute in isolation 1-2" in{
      specFoo mustBe susFoo
    }
    "execute in isolation 1-3" in{
      specFoo mustBe susFoo
    }
  }
  "sus2" should{
    val susFoo = new Object
    specFoo = susFoo
    "execute in isolation 2-1" in{
      specFoo mustBe susFoo
    }
  }
}

I'll keep on investigating and come back to you when I found out the root cause 
of 
this.

Original comment by etorrebo...@gmail.com on 11 Jan 2010 at 10:27

GoogleCodeExporter commented 9 years ago
Just to let you know: all of the problematic specs we had work when we 
converted them
from object to class. so the "spec as a class" workaround indeed seems to work.

Original comment by saynomoo@gmail.com on 12 Jan 2010 at 10:47

GoogleCodeExporter commented 9 years ago
Given this workaround and the specificity of the case, I'm closing the issue 
for now. 
Please reopen it if necessary.

Original comment by etorrebo...@gmail.com on 14 Jan 2010 at 8:23

GoogleCodeExporter commented 9 years ago

Original comment by etorrebo...@gmail.com on 31 Mar 2011 at 8:05