Parallelism #discussion

[Goutte]

Features and scenarios are executed in multiple workers, so there is a degree of unpredictability of the order of execution.

Is there ? I think the forEach method waits for one future to return before moving on the the next iteration.

As steps might (WILL) read and write to a common context, step order of execution is important, but scenario and feature order should not be, yeah.

[dkornishev]

It's actually a good practice to randomize the order of test scenarios. Are you saying they are not, due to the way forEach iterator works?

2014-06-29 13:56 GMT-04:00 Antoine Goutenoir [email protected]:

Features and scenarios are executed in multiple workers, so there is a degree of unpredictability of the order of execution.

Is there ? I think the forEach method waits for one future to return before moving on the the next iteration.

As steps might (WILL) read and write to a common context, step order of execution is important, but scenario and feature order should not be, yeah.

— Reply to this email directly or view it on GitHub https://github.com/dkornishev/dherkin/issues/39.

[Goutte]

Right now, both Features and Scenarios are run synchronously, as far as I can see.

See https://api.dartlang.org/apidocs/channels/stable/dartdoc-viewer/dart-async.Future#id_forEach

[Goutte]

We could always shuffle the hell out of the order, though.

[dkornishev]

Well that's not good. My intention was for features and scenarios in features to run in parallel. Otherwise not much point to using workers. Perhaps the futures that are given to forEach should complete immediately?

2014-06-29 14:20 GMT-04:00 Antoine Goutenoir [email protected]:

Right now, both Features and Scenarios are run synchronously, as far as I can see.

See https://api.dartlang.org/apidocs/channels/stable/dartdoc-viewer/dart-async.Future#id_forEach

— Reply to this email directly or view it on GitHub https://github.com/dkornishev/dherkin/issues/39#issuecomment-47465349.

[Goutte]

The fix is easy : just remove the return statement, see what happens ;)

[Goutte]

The problem with parallel runs is the lack of context-lock.

[dkornishev]

what's in the global context that can clobber runs?

Worker uses separate isolates that do not share contexts.

2014-06-29 14:27 GMT-04:00 Antoine Goutenoir [email protected]:

The problem with parallel runs is the lack of context-lock.

— Reply to this email directly or view it on GitHub https://github.com/dkornishev/dherkin/issues/39#issuecomment-47465861.

[Goutte]

Well, is the stepdefs context (user-defined) copied to each isolate ? (i don't grok isolates yet)

Wouldn't the slow scenario fail ?

  Background:
    Given I have a background setting a variable to a default value

  Scenario: Slow Scenario
    Given I set the background-setup variable to a different value
      And I wait for a few seconds
     Then the background-setup variable should hold the different value

  Scenario: Fast Scenario
    Given I set the background-setup variable to the default value
     Then the background-setup variable should hold the default value

[dkornishev]

Each scenario is executed in a separate isolate and isolates do not share state.

removing return of future on scenarios seems to work. Having trouble getting features to run in parallel

2014-06-29 14:38 GMT-04:00 Antoine Goutenoir [email protected]:

Well, is the stepdefs context (user-defined) copied to each isolate ? (i don't grok isolates yet)

Wouldn't the slow scenario fail ?

Background: Given I have a background setting a variable to a default value Scenario: Slow Scenario Given I set the background-setup variable to a different value And I wait for a few seconds Then the background-setup variable should hold the different value Scenario: Fast Scenario Given I set the background-setup variable to the default value Then the background-setup variable should hold the default value

— Reply to this email directly or view it on GitHub https://github.com/dkornishev/dherkin/issues/39#issuecomment-47466577.