Ability to communicate and store data from the slave nodes to the master node

[rayk47]

Description:

The ability to store data and communicate in the master node from the slave node when running tests in parallel.

Use case:

`
Scenario Outline: I add an activity for a user
Given I login as user ""
And I create a user new user with the following details:
| name | email | userType |
| test | test@test.com | athlete |
When I create a new activity with the details
| time | typeOfActivity | status |
| 12 | run | todo |
Then A new activity should be created

Scenario Outline: I add an activity for a user
    Given I login as user "<userName>"
    And I create a user new user with the following details:
        | name | email         | userType |
        | test | test@test.com | coach    |
    When I create a training plan
        | time | typeOfActivity | difficulty |
        | 12   | run            | hard   |
    Then A new training plan should be created

`
Imagine I have 50 or 60 tests that create these tests. I am going to be creating a lot of duplicate users in my given steps. Instead of reusing the users if they have already been created. Basically what I want is to build a cache of data in my Master node that can be shared across all slaves. At the moment I can build the cache that can check if the user already exists but that cache will only exist in my slave and cannot be shared across all slaves.

Solution:

Implement a way to communicate and store the data from my cache in the master node

I see there are commands currently to communicate between the slave and master but they are limited and could possibly be extended?
https://github.com/cucumber/cucumber-js/blob/master/src/runtime/parallel/command_types.js

[charlierudolph]

I personally don't like the idea of slaves sharing data they dynamically create. I also want to not build any parallel specific interfaces if we can avoid it. Thus I'd like to try to think of serial analogies when we are trying to build features.

How would you solve this in serial mode? Would you have some global that retains shared state that could be reused?

Also I wonder if the solution being discussed in #1153 would be of interest to you.

[davidjgoss]

Closing this now, because:

• It's been inactive for a long time
• There are no plans to add this functionality from the core team