Skip to content
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

First-class parallelism #1760

Open
mitchgrout opened this issue Aug 22, 2024 · 0 comments
Open

First-class parallelism #1760

mitchgrout opened this issue Aug 22, 2024 · 0 comments

Comments

@mitchgrout
Copy link

🤔 What's the problem you're trying to solve?

I have a suite of tests which take a long time to execute, but have no common resources that would prevent them from running in parallel. While I can use parallel_tests to speed up execution, one irritating limitation is that each process will have its own formatted output. This means I cannot easily see information like total executed/failed steps, the re-run list of failed scenarios, or have a singular HTML report generated. Further, since it randomly assigns features/scenarios to spawned processes, its possible for one or more processes to be stuck with a large number of slow-to-run features, which can lead to sub-optimal test run times.

✨ What's your proposed solution?

A work-stealing parallelism mode, which schedules at scenario-level, and can provide a cohesive output from a single process. This should address the issue of having multiple independent outputs, and sub-optimal splits.

⛏ Have you considered any alternatives or workarounds?

I have had success with parallel_tests and a custom tool I wrote to merge .ndjson data files, which allowed me to continue using the standard HTML reporter. However, this requires some conditional config in my cucumber.yml to ensure .ndjson is emitted when running in parallel, and to suppress all other outputs. I have not yet found a way to resolve the issue of sub-optimal splits.

📚 Any additional context?

There are a few outstanding questions I'm not sure of, which would limit the possibility of this feature:

  1. How would this interact with the wire protocol plugin? Typically this assumes a singular connection which all tests could be streamed through. Should parallelism be disabled if a wire connection is configured?
  2. How much rework would be required to implement this? Since tests are orchestrated around the event-bus, which as I understand assumes a sequential workflow, how could this be achieved?
  3. If parallelism is implemented, what would this mean for steps which require interactivity such as aruba? Could these steps assert something like not parallel?, or would this not be acceptable?

While I may be misreading the documentation, it appears that the Java implementation may also support some rudimentary parallel test execution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant