This app's spec suite, timed, runs in one process

The numbers, measured

$ bundle exec rspec spec/
...
Finished in 1 minute 19.03 seconds (files took 2.87 seconds to load)

That's this app's spec suite, run for this course: 205 spec files and 1,219 examples. RSpec reports 1 minute 19.03 seconds of run time. Loading the files beforehand, requiring every spec, factory and support file before a single example runs, took another 2.87 seconds. Every number in this course comes from running the suite, not from a general estimate of what an app this size usually takes.

One process, start to finish

bundle exec rspec spec/ starts one Ruby process, loads Rails once, connects to one database and runs every example through that process, one after another, in the order RSpec's configured test order picks. No flag on that command, no line in spec/spec_helper.rb or spec/rails_helper.rb and no environment variable splits any of that work across more than one process. The next six lessons follow the question that raises: could more than one process make this faster, and does this app have the pieces to try it?

This app's CI doesn't run the suite

.github/workflows/ci.yml defines three jobs: scan_ruby (runs bin/brakeman), scan_js (runs bin/importmap audit) and lint (runs bin/rubocop). Read line by line, all 63 lines, the file has no job that runs bundle exec rspec. The suite only runs where a developer runs it by hand; it isn't part of the automated checks on this repository's pull requests. That's a separate finding worth stating before going further. The question "should this run in parallel" sits next to another one, "where does this run at all", and this course covers only the first.

Neither of the two parallel-testing mechanisms is configured here

$ grep -rn "parallelize\\|parallel_tests\\|PARALLEL_WORKERS" spec/ config/ Gemfile
# (no output)

Nothing comes back. There are two different answers to "run my tests in parallel" in the Rails world, one built into ActiveSupport::TestCase for Minitest and one a separate community gem for RSpec, and this app uses neither.

What this course covers

Seven lessons, with each number and each piece of source checked against this app's installed Rails 8.1.3.1 and its repository. Lesson 2 covers Minitest's ActiveSupport::TestCase.parallelize, and why this RSpec app can't use it. Lesson 3 covers RSpec's answer, the separate parallel_tests gem, from its README. Lesson 4 covers how that gem decides which spec files go to which process. Lesson 5 covers the multiple-database convention its parallel runs depend on, checked against this app's config/database.yml. Lesson 6 gives a numbers-based answer to whether parallelizing a suite this size would help. Lesson 7 ends with a small, plain-Ruby challenge that simulates the same load-balancing idea in miniature.