如何诊断不依赖执行顺序的间歇性Rspec测试失败？

背景 #

我知道rspec --bisect可以用来隔离依赖执行顺序的间歇性失败测试，但现在碰到一个遗留应用（完全没接触过这个代码库），里面有个测试单独运行也会间歇性失败——执行顺序根本不是影响因素。

具体来说，运行：

rspec ./spec/services/locate_missing_approver_service_spec.rb:5

大概每10次会失败1次。这个10%的比例是经验估算，如果能准确统计这个数据，我就能用git bisect定位到导致测试不稳定的起始提交。

目前我自己写了个函数来检查特定提交或临时代码修改下会不会出现失败，也可以扩展它来收集统计数据，但不确定这是不是最优方案：

function test-flaky-spec() {
  while true; do
    rspec ./spec/services/locate_missing_approver_service_spec.rb:5
    if [[ $? -ne 0 ]]; then
      break
    fi
    sleep 0.1
  done
}

核心问题 #

针对这种独立运行仍不稳定的测试，有没有通用的故障排查技巧？

通用排查技巧 #

1. 先量化失败概率，为git bisect铺路 #

你现在的脚本是直到失败就停止，可以改成统计N次运行的失败率，这样能准确判断某个提交是否引入了不稳定：

function test-flaky-stats() {
  RUNS=50
  FAILS=0
  for ((i=1; i<=RUNS; i++)); do
    echo "Running test #$i..."
    rspec ./spec/services/locate_missing_approver_service_spec.rb:5 > /dev/null 2>&1
    if [[ $? -ne 0 ]]; then
      ((FAILS++))
    fi
  done
  echo "Total runs: $RUNS, Failures: $FAILS, Failure rate: $((FAILS*100/RUNS))%"
}

这个脚本跑50次（可调整次数），输出明确的失败率，方便git bisect时快速判断当前提交是否存在问题。

2. 给测试加详细日志，捕捉失败瞬间的状态 #

既然测试偶尔失败，就在测试代码的关键步骤加日志，打印依赖的变量值、外部服务响应、数据库状态等。比如在测试里：

it "locates missing approver" do
  # 打印测试执行时的上下文数据
  puts "Current user: #{user.inspect}"
  puts "Approval records count: #{Approval.count}"
  
  result = LocateMissingApproverService.call(user)
  
  # 失败时强制输出结果
  puts "Service result: #{result.inspect}" unless result.success?
  
  expect(result).to be_success
end

也可以用RSpec的--format documentation参数，让失败时输出更完整的上下文信息。

3. 检查测试依赖的外部因素 #

独立运行还不稳定，大概率和外部依赖有关：

• 数据库状态：测试有没有正确清理数据？比如是否用了let!提前创建数据，有没有事务回滚遗漏？可以在测试前后打印数据库表的行数，排查是否有脏数据残留。
• 时间/随机因素：测试里有没有用当前时间（比如Time.now）、随机数？比如服务逻辑依赖时间窗口，测试时如果时间刚好卡边界就会失败。可以把时间固定成常量，或者用timecop这类gem冻结时间试试。
• 外部服务/API：如果服务调用了外部接口，有没有做模拟？模拟的返回是不是固定的？如果用了真实接口，网络波动、服务延迟都可能导致失败，换成固定的模拟响应试试。

4. 用调试工具卡住失败场景 #

当测试失败时，自动触发调试：

• 在测试里加条件断点，比如：

it "locates missing approver" do
  result = LocateMissingApproverService.call(user)
  
  unless result.success?
    require 'pry'; binding.pry # 失败时进入调试
  end
  
  expect(result).to be_success
end

• 或者修改你的脚本，失败时保留测试输出并暂停：

function test-flaky-debug() {
  while true; do
    rspec ./spec/services/locate_missing_approver_service_spec.rb:5
    EXIT_CODE=$?
    if [[ $EXIT_CODE -ne 0 ]]; then
      echo "Test failed! Output above, press Enter to continue..."
      read
    fi
    sleep 0.1
  done
}

这样每次失败都能看到完整错误信息，甚至手动调试现场状态。

5. 检查代码里的竞态条件 #

如果服务里有并发逻辑（比如多线程、异步任务），即使测试单线程运行，也可能因为代码里的竞态条件导致结果不稳定：

• 有没有共享的全局变量？
• 数据库操作有没有加锁？比如多个请求同时修改同一条记录，导致状态不一致。
• 异步任务有没有在测试里同步执行？比如用了Sidekiq，测试时有没有Sidekiq::Testing.inline!确保任务立即执行？

6. 缩小测试范围，定位到具体代码行 #

把测试拆分成更小的步骤，逐步验证每个环节的结果，比如原来的测试是调用服务然后断言结果，可以拆成：

it "locates missing approver" do
  # 第一步：检查初始状态
  expect(Approval.where(user: user).pending.count).to eq(3)
  
  # 第二步：调用服务
  result = LocateMissingApproverService.call(user)
  
  # 第三步：检查中间状态
  expect(result.missing_approvers).to match_array([approver1, approver3])
  
  # 第四步：最终断言
  expect(result).to be_success
end

这样每次失败就能知道是哪个环节出问题，大幅缩小排查范围。

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