大量关联测试数据拖慢RSpec Request Specs 如何兼顾速度与测试隔离？

现有方案的问题 #

你提到的两种方案都存在明显缺陷：

• 全量let!每次重建数据：所有关联记录每次测试都触发数据库写入，20-30条带关联的记录单次写入就需要数百毫秒，用例数量上来后耗时会指数级增长
• before(:all)手动恢复修改数据：关联关系复杂的场景下很容易出现漏恢复的修改（比如回调触发的隐藏字段变更、关联表数据变更），会造成用例间状态污染，debug成本极高，不推荐使用

最优落地方案：事务回滚 + 分层数据准备 #

这个方案可以同时保证测试隔离性和执行速度，不需要手动维护测试状态，是行业内通用的成熟方案：

第一步：开启事务测试基础能力 #

RSpec 默认支持事务回滚的测试隔离机制，在每个测试用例启动前开启数据库事务，测试结束后直接回滚事务，所有用例执行过程中的数据修改都会被数据库层面撤销，不会留下任何残留数据，完全保证测试隔离。
只需要在spec/rails_helper.rb中开启对应配置即可：

RSpec.configure do |config|
  # Request Spec 单线程场景下默认配置即可生效，多线程测试可配合 database_cleaner gem的事务策略使用
  config.use_transactional_fixtures = true
end

第二步：分层准备测试数据降低写入开销 #

把测试数据按是否会被修改拆分，分别用不同的生命周期创建：

• 完全不会被修改的公共基础数据：比如通用枚举配置、全局主数据、所有用例共用的关联基础数据，放在before(:all)中一次性创建，整个测试文件只写入一次，不存在状态污染问题
• 会被测试用例/API修改的可变数据：用let!或者before(:each)创建，因为只有这部分数据需要每次重建，数量会从原来的20-30条降低到几条，写入开销大幅下降。如果这部分数据量依然很大，可以配合activerecord-import这类批量插入工具，比逐条创建速度提升5-10倍，30条带关联的记录批量写入仅需不到100ms，完全不会成为性能瓶颈

特殊场景兼容方案 #

如果你的测试场景中几乎所有数据都需要修改，没有多少公共基础数据，可以用「before(:all)一次性创建全量数据 + 事务回滚 + 用例执行前reload加载数据」的方案：所有修改都会被事务回滚撤销，下一个用例reload拿到的永远是初始状态的干净数据，比手动恢复实例变量的方案靠谱得多，性能和手动恢复的方案基本一致，隔离性有数据库层面的保障。

最终选型建议 #

• 公共不可变数据占比超过60%的场景：优先选择「before(:all)放公共数据 + 事务回滚 + 可变数据按需创建」的方案，兼顾性能和隔离性
• 几乎所有数据都需要修改的场景：优先选择「事务回滚 + 批量插入创建全量数据」的方案，不需要修改太多现有测试逻辑，性能提升明显
• 不要选择手动维护before(:all)修改恢复的方案，人力维护的状态一致性远不如数据库事务回滚可靠

内容的提问来源于stack exchange，提问作者Alexandru Robert