为何Rubocop更推荐使用`have_received`而非`receive`？

你的两种测试写法，核心区别在于断言时机和测试结构，Rubocop推荐的写法好处远不止遵循AAA格式：

1. 清晰分离测试阶段 #

allow(ClassA).to receive(:method)属于准备阶段（Arrange），先配置好模拟对象的行为；ClassB.perform是执行阶段（Act），运行被测试的业务代码；最后expect(ClassA).not_to have_received(:method)是验证阶段（Assert），检查执行结果。这种拆分让测试逻辑一目了然，哪怕是复杂测试，其他人也能快速看懂每个步骤的作用。

2. 支持更灵活的验证场景 #

前置的expect(...).to receive(...)只能预先声明“这个方法必须被调用”，如果要验证没有被调用、或者被调用了N次、或者调用时的参数符合要求，前置写法会非常受限。而先allow再用have_received，可以在执行完代码后按需组合各种断言，比如：

# 验证被调用了2次
expect(ClassA).to have_received(:method).twice
# 验证调用时传了指定参数
expect(ClassA).to have_received(:method).with('param')

3. 避免前置断言的干扰 #

前置的expect(...).to receive(...)本质是给方法绑定了一个“断言式的桩”，如果代码里方法被调用的次数、时机不符合前置声明，测试会直接失败，但这种失败可能不是因为业务逻辑错误，而是前置断言的约束太死。而allow只是给方法打一个普通的桩，不预设调用要求，事后用have_received验证实际调用情况，更贴近代码执行的真实状态，减少误判。

4. 统一团队测试风格 #

Rubocop的这个规则本质是推动团队采用一致的测试范式，让所有测试都遵循相同的结构，降低新人学习成本，也让测试代码的维护性更强。

两种写法对比 #

原写法（前置断言）：

expect(ClassA).to receive(:method)
ClassB.perform

推荐写法（AAA结构）：

allow(ClassA).to receive(:method)
ClassB.perform
expect(ClassA).not_to have_received(:method)

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