search

dkornishev / dherkin

Cucumber gherkin runtime for dart
BSD 2-Clause "Simplified" License
8 stars 5 forks source link

Parallelism #discussion #39

Open Goutte opened 10 years ago

Goutte commented 10 years ago

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 commented 10 years ago

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 notifications@github.com:

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 commented 10 years ago

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 commented 10 years ago

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

dkornishev commented 10 years ago

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 notifications@github.com:

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 commented 10 years ago

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

Goutte commented 10 years ago

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

dkornishev commented 10 years ago

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 notifications@github.com:

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 commented 10 years ago

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 commented 10 years ago

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 notifications@github.com:

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.