Optimize CI test speed with Minitest parallelization and test infrastructure improvements

[paracycle]

Motivation

CI test runs were taking ~22 minutes on average (up to ~27 minutes for the slowest matrix job). Most of this time was spent in subprocess overhead: each CLI test creates a temporary project, runs bundle install, and invokes bundle exec tapioca <command> — spawning ~95 bundle install processes and many tapioca subprocesses per run.

Implementation

This PR introduces serial test infrastructure optimizations and in-process parallel test execution via Minitest's built-in parallelize_me!, reducing CI time by ~34%.

Serial optimization breakdown (cumulative):

Optimization	Time	Improvement
Baseline (main)	~600s	—
Default reporter + Rails log silencing + minitest/hooks	~580s	~3%
Gemfile.lock content-hash caching	~420s	~28%
bundle install flags (--jobs=4 --quiet --retry=0)	~400s	~5%
Prism.parse replacing sorbet subprocess syntax check	~370s	~8%
ENFORCE_TYPECHECKING=0 in tapioca subprocesses	~340s	~8%
TAPIOCA_SKIP_VALIDATION=1 in tapioca subprocesses	~330s	~3%
In-process configure! replacing subprocess calls	~320s	~3%
Total serial improvement	~320s	~47%

Parallel execution via parallelize_me!

A Tapioca::Helpers::Test::Parallel module (25 lines) calls parallelize_me! on any test class that includes it, enabling Minitest's built-in thread pool for safe classes. Thread count is controlled by the MT_CPU env var (defaults to Etc.nprocessors).

12 test classes include the module:

• DslSpec (+ 38 subclasses) — 374 DSL compiler tests that use fork-based isolation
• PipelineSpec — 120 gem pipeline tests with fork-based isolation
• BuilderSpec, CompilerSpec, ExecutorSpec, RBIHelperSpec, SorbetHelperSpec, ReflectionSpec, GenericTypeRegistrySpec, ActiveModelTypeHelperSpec, GraphqlTypeHelperSpec, LockFileDiffParserSpec — unit tests with no shared state

Classes using minitest-hooks' before(:all)/after(:all) (all SpecWithProject subclasses) remain serial, since parallelize_me! bypasses the with_info_handler lifecycle that minitest-hooks relies on.

Gemfile.lock caching (spec/helpers/mock_project.rb)

• Caches lockfile resolution by content-hashing the Gemfile and all referenced gemspec files
• Still runs bundle install after cache hit to ensure gems are actually installed, but skips slow dependency resolution
• Serializes all bundle install calls under a global exclusive file lock to prevent concurrent gem directory corruption

Subprocess overhead reduction

• ENFORCE_TYPECHECKING=0: Disables sorbet runtime type checking in tapioca subprocesses (~40% faster per invocation)
• TAPIOCA_SKIP_VALIDATION=1: Skips sorbet static validation in test subprocesses (tests that specifically validate this behavior opt out)
• In-process configure! method replaces tapioca("configure") subprocess calls where possible
• Replaces sorbet subprocess syntax checking with in-process Prism.parse in DSL compiler tests

Minor test infrastructure improvements

• Default minitest reporter instead of SpecReporter (less I/O)
• config.log_level = :fatal for Rails logger
• --jobs=4 --quiet --retry=0 flags for bundle install
• Increased addon_spec timeout from 4s to 30s for CI resilience

CI Results

Metric	Main (baseline)	This PR	Improvement
CI average per job	22.4m	14.8m	34% faster
CI fastest job	19.3m	13.3m	31% faster
CI slowest job	26.8m	17.0m	37% faster

All 14 CI matrix jobs pass (Ruby 3.2/3.3/3.4/4.0/head × Rails 8.0/current/main).

Tests

Existing test suite is unchanged and all tests pass. The bin/test entry point is unmodified — all parallelism is opt-in via include Tapioca::Helpers::Test::Parallel in individual test classes. One pre-existing test (run_gem_rbi_check_spec.rb) hangs on Ruby 4.0 due to an Open3.capture3/Bundler.with_unbundled_env interaction unrelated to this PR.

[amomchilov]

Still working through reviewing spec/helpers/mock_project.rb, but the rest looks good so far. Left a few questions/comments

[amomchilov]

Why not call parallelize_me! directly?

[amomchilov]

Is this because we're expecting more CPU contention, now that we might actually be fully saturating multiple threads?

[amomchilov]

Are we ok with giving this up?

[amomchilov]

Can you please add a comment to explain that this is a performance optimization?

[amomchilov]

Actually, this would still be making syscalls. Wanna use a NullLogger like so?

class NullLogger
  include Singleton

  # : (*untyped) -> nil
  def unknown(*) = nil
  # : (*untyped) -> nil
  def fatal(*) = nil
  # : (*untyped) -> nil
  def error(*) = nil
  # : (*untyped) -> nil
  def warn(*) = nil
  # : (*untyped) -> nil
  def info(*) = nil
  # : (*untyped) -> nil
  def debug(*) = nil
  # : (untyped) -> nil

  # : () -> bool
  def fatal? = false
  # : () -> bool
  def error? = false
  # : () -> bool
  def warn? = false
  # : () -> bool
  def info? = false
  # : () -> bool
  def debug? = false

  def level=(_)
    nil
  end
end

Suggested change

	config.logger = Logger.new('/dev/null')
	config.logger = NullLogger.instance

I'm curious to measure how much it might help