Parallel scenarios?

[xtrasimplicity]

Hi there,

Firstly, thanks for creating such a useful gem - it's helped reduce the duration of our CI pipelines tremendously!

This may be indicative of issues in the size of our RSpec features, but I've noticed that parallel_tests seems to work best with a one-scenario-per-file setup. That is, if there's 10 scenarios in a single RSpec spec file, parallel_tests detects it as one test and "allocates" it to one runner.

Is there currently a way to "extract" all specs from a file, in such a way that multiple runners could process different specs in a single file at once?
i.e. Given the following spec file:

# my_feature_spec.rb
require 'spec_helper'
RSpec.describe 'My Cool feature', type: :feature do
  it 'does the first thing' do
 end
  it 'does another thing' do
 end
end

I would expect the following on a machine with 2 CPUs/cores:

CPU 0:  my_feature_spec:3
CPU 1: my_feature_spec:5

Is this possible? If not, would you be open to a PR adding this?

Thanks!

[xtrasimplicity]

@grosser, apologies for the ping, but any thoughts on this one? :)

[grosser]

https://github.com/grosser/parallel_split_test does what you want

parallel_tests is trying to stay at the file level to keep the integration simple

[grosser]

this talks about parallel scenarios for cucumber, might do the trick or get close to a solution #679

[xtrasimplicity]

Thanks, @grosser - much appreciated!

Would you be open to a PR which updates the Readme to mention that parallel_tests is intended to act at the file-level, and to recommend parallel_split_test where test-level concurrency is required?

[grosser]

sounds good! ... best under tips section or so

…

On Sun, Feb 2, 2020 at 12:37 PM Andrew ***@***.***> wrote: Thanks, @grosser <https://github.com/grosser> - much appreciated! Would you be open to a PR which updates the Readme to mention that parallel_tests is intended to act at the file-level, and to recommend parallel_split_test where test-level concurrency is required? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#747?email_source=notifications&email_token=AAACYZ7FLUQNJHK5LDVEJZ3RA4VHNA5CNFSM4KMIB6V2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKSAJ7Y#issuecomment-581174527>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAACYZ43MJJTUJQ2RHD3UJDRA4VHNANCNFSM4KMIB6VQ> .

[stevenharman]

It's been… a few years since you said the following, and I'm wondering if your opinion holds:

https://github.com/grosser/parallel_split_test does what you want. parallel_tests is trying to stay at the file level to keep the integration simple

I bring this up because while parallel_split_test does split individual tests across Processes, rather than splitting by file, it's also:

not as robust or well-documented, more of a POC that I never really ended up using in any big project

Given that, it makes sense that parallel_split_test is missing features exist in parallel_tests. For example, ParallelTests.first_process? and ParallelTests.wait_for_other_processes_to_finish are especially useful for setting up and tearing down shared resources. Context: We were trying to use those mechanisms to set up a test-specific Redis instance, using a named Redis DB for each test process, and then tearing that Redis down at the end of the last test Process. But parallel_split_test lacks those mechanisms.

So I'm wondering… would you be open to adding another splitting strategy to split individual tests across the Processes. Ideally we'd have a way to do pull-based splitting of tests, as was attempted with turbo_test, but it doesn't seem like that went very far. Maybe if/when we finally get first-class parallel test support in RSpec.

More realistically, (and II haven't looked into it yet, but…) I wonder how hard it would be to pull over the simple, but rather effective, technique parallel_split_test uses? If you're open to adding a new strategy, I'm happy to do some leg work to look into adding it.

Thank you for your time.

[grosser]

doing that would completely change the architecture (or I guess add a completely new architecture), so prefer copying what is needed to parallel_split_test instead