496: Test suite performance

What It Covers

Joelle Kenville and Sally Hall from Thoughtbot examine test suite performance across three interconnected levers: FactoryBot versus fixtures as data strategies, the testing pyramid versus trophy models, and parallelization math — including how Rails boot time creates hard diminishing returns when scaling worker counts.

Key Questions Answered

• •FactoryBot base factory rule: Define only the minimum fields required for a record to pass Active Record validations and save to the database. Any additional fields — even logically necessary associations — add unnecessary database round trips. Every extra `create` call compounds across thousands of tests, making this single discipline one of the highest-impact performance changes available.
• •Fixtures vs. factories team fit: Fixtures pre-write all test data once before the suite runs, making them faster than factories in nearly every benchmark. However, they require a stable, small team with strong communication to maintain a shared data "story." Large teams, high-churn environments, or rapidly growing codebases will likely see fixture files degrade into inconsistent, duplicated records over time.
• •Parallelization boot-time math: Each parallel worker pays the full Rails boot cost — potentially 60+ seconds on large apps. If adding a worker only reduces test runtime by 10 seconds while costing 60 seconds of boot overhead, parallelization stops moving the needle. At that threshold, reducing boot time via lazy loading becomes more effective than adding more workers.
• •LLM-assisted git archaeology: Passing a git log to an LLM with a prompt asking for commit SHAs and decision rationale produces a structured report — in roughly 30 seconds — explaining why code evolved, what race conditions were patched, and which hacks became load-bearing. The technique works reliably because the LLM operates on a bounded, concrete dataset with low hallucination risk.
• •Deleting tests after development: Not every test written during TDD or bug-fixing needs to remain in the suite permanently. A complex system test written to reproduce a specific JavaScript edge case may become redundant once the underlying model method is unit-tested directly. Retaining it adds CI runtime and maintenance cost without proportional coverage value.