下面的代码对我来说很好，也适用于多个测试用例和测试retry_on块的副作用。

RSpec.describe MyJob, type: :job do
  include ActiveJob::TestHelper

  context 'when `MyError` is raised' do
    before do
      allow_any_instance_of(described_class).to receive(:perform).and_raise(MyError.new)
    end

    it 'makes 4 attempts' do
      assert_performed_jobs 4 do
        described_class.perform_later rescue nil
      end
    end

    it 'does something in the `retry_on` block' do
      expect(Something).to receive(:something)

      perform_enqueued_jobs do
        described_class.perform_later rescue nil
      end
    end
  end
end

请注意，如果您让异常在最后冒泡，则需要rescue nil（或某种形式的救援）。
请注意，perform_now不算作“排队作业”。因此，执行described_class.perform_now会导致assert_performed_jobs计数的尝试次数减少一次。

这是retry_on所需的规范格式，最终对我有效：

it 'receives retry_on 10 times' do
  allow_any_instance_of(MyJob).to receive(:perform).and_raise(MyError.new(nil))
  allow_any_instance_of(MyJob).to receive(:executions).and_return(10)
  expect(Bugsnag).to receive(:notify)
  MyJob.perform_now(an_object)
end

it 'handles error' do
  allow_any_instance_of(MyJob).to receive(:perform).and_raise(MyError.new(nil))
  expect_any_instance_of(MyJob).to receive(:retry_job)
  perform_enqueued_jobs do
    MyJob.perform_later(an_object)
  end
end

对于第一种情况，executions是一个ActiveJob方法，每次执行retry_on时都会运行、设置和检查。我们模拟它返回10，然后期望它调用Bugsnag。retry_on只在满足所有attempts后调用你在块中给它的值。这么说行得通
对于第二种情况，然后模拟错误以引发作业示例。接下来，我们检查它是否正确地接收了retry_job（retry_on在后台调用它），以确认它正在做正确的事情。然后，我们将perform_later调用 Package 在minitestperform_enqueued_jobs块中，并就此结束。

恕我直言，你应该把ActiveJob的测试留给Rails团队。
您只需要确保您正确配置作业：

it 'retries the job 10 times with 2 minutes intervals' do
  allow(MyJob).to receive(:retry_on)
  load 'app/path/to/job/my_job.rb'
  expect(MyJob).to have_received(:retry_on)
    .with(
      Exception,
      wait: 2.minutes,
      attempts: 10
    )
end

虽然我同意@fabriciofreitag的观点，即不需要测试外部库的内部，但我认为确认retry_on块配置正确肯定有价值。这个设置对我来说很有效，而不必担心ActiveJob如何管理重试。

# app/jobs/my_job.rb
retry_on TimeoutError,
         wait: :exponentially_longer,
         attempts: 3

# spec/jobs/my_job_spec.rb
describe "error handling" do
  before do
    ActiveJob::Base.queue_adapter.perform_enqueued_at_jobs = true
  end

  context "when TimeoutError is raised" do
    it "retries timed-out requests" do
      expect(client).to receive(:connect).ordered.and_raise(TimeoutError)
      expect(client).to receive(:connect).ordered.and_call_original
      described_class.perform_now
    end

    it "retries three times before re-raising" do
      expect(client).to receive(:connect)
        .exactly(3).times.and_raise(TimeoutError)
      expect { described_class.perform_now }.to raise_error(TimeoutError)
    end
  end
end

在第一个规范中，

expect(MyJob).to receive(:retry_on).with(wait: 2.hours, attempts:3).exactly(3).times

这将永远不会工作，因为类方法retry_on将在类初始化阶段被调用，即在将该类加载到内存中时，而不是在执行规范时
在第二个规范中，您尝试使用timecop使其工作，但由于相同的原因仍然失败
第三个规格相对更现实，但

assert_performed_jobs 3

不通过关卡就不行
事

assert_performed_jobs 2 do
  //call jobs from here
end

我的小型测试解决方案：

class ExecuteJob < ApplicationJob
  RETRY_LIMIT = 30
  RETRY_DELAY = 1.second

  retry_on ExpectedErrorClass, wait: RETRY_DELAY, attempts: RETRY_LIMIT

  def perform
   # your code
  end
end

test 'retries run job' do
  assert_performed_jobs(described_class::RETRY_LIMIT) do
    perform_enqueued_jobs do
      assert_raises ExpectedErrorClass do
        described_class.perform_later
      end
    end
  end
end