TestProf: RSpec Performance Optimization

Expert guidance for diagnosing and fixing slow RSpec test suites. Based on field-tested techniques from Evil Martians' work reducing a 30,000-spec Rails suite from 4m30s to 2m (and targeting 1m30s with parallelization).

The core idea: slow test suites are rarely slow for one reason. They're slow for a handful of fixable reasons, stacked. This skill walks you through diagnosing which reasons apply, then fixing each one — in an order that avoids wasted effort.

How to use this skill

When a user brings a slow RSpec suite, investigate their actual codebase before prescribing anything. A skill full of generic advice is worse than useless — the value is in mapping the general patterns onto their specific code. Follow this order:

1. Characterize the problem — ask for total runtime, example count, and whether it's "slow everywhere" or "slow in specific files." This determines which profiler to run first.
2. Investigate concretely, don't speculate. Before giving advice, actually:
   • Read spec/spec_helper.rb and spec/rails_helper.rb for suspicious requires (rubocop/rspec/support, SimpleCov config, global hooks).
   • Grep the Gemfile for the suspects: SimpleCov, blind_index, any encryption gem, retry gems (retriable, Faraday retry middleware).
   • For slow individual specs, read the service file being tested — grep for sleep, retry, ObjectSpace, create_list(:..., with large numbers.
   • Look at the factory definitions for the types involved. Association fan-out is a common cause. This is the difference between a suggestion list and a diagnosis. Always do the investigation first.
3. Run the right diagnostic next — see "Diagnostic decision tree" below. If Claude can't run the profiler (no shell access to the user's env), write the exact commands the user should run and explain how to interpret the output.
4. Apply fixes in order of payoff — coverage and GC issues often give the biggest single wins and require the least invasive changes, so check them before rewriting specs.