Investigate possibility of running RSpec tests in parallel on the predictive command

Overview

Currently, when running the gdk predictive command, we execute RSpec tests sequentially, which can take a long time while only utilizing a fraction of the available computing resources. This issue is about looking into the possibilities of running tests in parallel to use local computing resources more efficiently and reduce the overall runtime of local RSpec tests.

Impacted categories

The following categories relate to this issue:

• gdk-reliability - e.g. When a GDK action fails to complete.
• gdk-usability - e.g. Improvements or suggestions around how the GDK functions.
• gdk-performance - e.g. When a GDK action is slow or times out.

Steps to replicate

1. Run gdk predictive --rspec.
2. See that multiple tests are run in parallel.

Known challenges

@kkloss:

This is a broader problem with RSpec, or rather Rails tests. Specs within a Rails project are not meant to be run in parallel by default.
We can run multiple RSpec processes at the same time but if they interact with the database, this might introduce flakiness.
For example, a spec that expects that there is one issue created after clicking New issue (expect { click 'New issue' }.to change { Issue.count }.by(1)). But what if another spec just deleted an issue in the database.
So there are a lot of assumptions when running RSpec that we can no longer trust. (I’m not saying it’s unsolvable, it’s just difficult. For example, we could have multiple test databases like we effectively have in CI by parallelizing. Or crazy ideas like running local RSpec executions actually on dedicated test infrastructure.)