-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
within a story, {after} block executed not after all scenarios, but right after {before} block #9
Comments
Could you provide your scenario?
|
As far as I know, the scenario is the one below. Instead of parsing first and then executing, it looks like easyb is executing in parsing phase … import org.easyb.exception.VerificationException Logger log = Logger.getLogger("Issue103.story") before "setup string", {
} after "tear down", {
} scenario "Validate setup and teardown", {
} if (var != "set in after") { throw new VerificationException("after closure doesn't appear to be working!") } Cheers JürgenJürgen Kindler Von: Richard Vowles <[email protected]mailto:[email protected]> Could you provide your scenario?
— |
Another example:
Order of execution is before |
It should parse these and collect the closure blocks before execution of This was a documented behaviour change from the 0.x version to support the
|
Hi Richard, I am not sure what you mean with "It should parse these and collect the closure blocks before execution of the closure blocks" ? I played a bit with this method and added conditions for before[_each] and after[_each] to store the closures in the StoryContext variables BehaviorStep beforeScenarios BehaviorStep afterScenarios BehaviorStep beforeEach BehaviorStep afterEach But some of the test cases – e.g. in org.easyb.bdd.prototype (OneTimeFixtureFeature) require the direct execution of some blocks (as otherwise variables that get defined inside closures in these test cases would otherwise be undefined when the last script statement gets executed). If I modify my example a little bit I (and use the checked-in version of the logic) get a failure that shows what happens by the content of the variable var. When I execute: Logger log = Logger.getLogger("Issue103.story") before "setup string", { after "tear down", { scenario "Validate setup and teardown", { println "var = $var" I get the following output (contains a little more than the expected lines as I added a bit of logging also in StoryProcessing and StoryKeywords: I was not involved in the design & implementation of the execution model, so this triggers a couple of questions in my head:
I'm sure you know more about that – for myself I have to admit that I still lack understanding the code :-( Cheers Jürgen Kindler Von: Richard Vowles <[email protected]mailto:[email protected]> It should parse these and collect the closure blocks before execution of This was a documented behaviour change from the 0.x version to support the
— |
On Mon, Feb 3, 2014 at 8:27 PM, Jürgen Kindler [email protected]:
Thats just Groovy scripts, so normally you don't use def anywhere in your
Yes, I was working on my own at that point and I really think I missed
The groovy interpretor is just executing them sequentially - the closure
It should go: before, before_each/scenario/after_each, after - as you would
It took me ages to figure it all out. But this bug is clearly a bug as it Richard Vowles, ph: +64275467747, web: www.google.com/+RichardVowles |
Thanks, Richard! Cheers JürgenJürgen Kindler Von: Richard Vowles <[email protected]mailto:[email protected]> On Mon, Feb 3, 2014 at 8:27 PM, Jürgen Kindler <[email protected]mailto:[email protected]>wrote:
Thats just Groovy scripts, so normally you don't use def anywhere in your
Yes, I was working on my own at that point and I really think I missed
The groovy interpretor is just executing them sequentially - the closure
It should go: before, before_each/scenario/after_each, after - as you would
It took me ages to figure it all out. But this bug is clearly a bug as it Richard Vowles, ph: +64275467747, web: www.google.com/+RichardVowles — |
Hi Richard, I have gotten closer to solving this issue, but I feel the solution is only partially. import org.easyb.exception.VerificationException import java.util.logging.Logger Logger log = Logger.getLogger("Issue103.story") def var = "" def addInBefore = "In before" def addInBeforeEach = " + in each before" def addInGiven = " + in given" def addInAfter = " + in after" def addInAfterEach = " + in each after" before "[Before block", {
} before_each "[Before_each block", {
} after "After block]", {
} after_each "After each block]", {
} scenario "Validate setup and teardown", {
} The result is unfortunately: So the green parts in the actual value is what would be expected from execution and the red ones are related to "parsing". So at least they get executed also when they should be executed, but unfortunately not exclusively then. Cheers Jürgen Kindler |
With version 1.6 that problem should be fixed. |
I tried to upgrade to easyb-core 1.5 (from easyb 0.9.7_1) and stumbled upon very strange behavior described in title of this issue. Is this a known issue, or misconfiguration, or just needs to be investigated and fixed?
The text was updated successfully, but these errors were encountered: