RSpec不同作用域下方法调用报错，如何解决循环测试报错

两类报错的核心成因 #

两个报错看似相反，本质是最初的全局配置故障触发了误操作，调整后产生的次生错误：

• 带it块的标准断言写法报的name不可用错误，和测试代码本身完全无关。报错堆栈直接指向spec_helper.rb的全局配置段，说明RSpec自身在运行示例的流程中，调用了只能在示例组（describe/context块的类层级上下文）才能访问的name方法，属于典型的配置代码作用域越界，不是测试断言的问题。
• 把断言塞到裸describe块里后报的have_many不可用错误，是误调整作用域导致的次生问题。Shoulda匹配器提供的have_many这类断言方法，天生就是设计来在示例（it块的实例作用域）下调用的，放到示例组的类层级上下文里，自然找不到对应方法。

实际解决步骤 #

• 先把测试代码恢复为RSpec+Shoulda的标准写法，不要随意挪动断言位置：

  require 'rails_helper'
  
  RSpec.describe Todo, type: :model do
    it { should have_many(:items).dependent(:destroy) }
  end
  

• 逐行排查spec/spec_helper.rb和spec/rails_helper.rb里的全局配置，重点检查两类容易触发越界调用的代码：
  • 写在before(:each)/after(:each)这类示例级钩子中的逻辑：不要在这类钩子里直接调用示例组类的name方法，这类方法在示例执行阶段没有绑定合法的上下文，直接调用就会触发报错。
  • 自定义的测试报告、日志输出逻辑：如果需要在示例运行阶段打印测试所属的模型名称，必须通过RSpec提供的公开元数据API（比如RSpec.current_example.metadata）获取信息，不要直接操作示例组类本身的方法。
• 如果项目处于初期阶段，没有沉淀复杂的自定义配置，最快的修复路径是重新执行rails generate rspec:install，覆盖生成标准的基础配置文件，再逐行补回自定义逻辑，每加一段配置就运行一次测试，快速定位到底是哪段配置触发的作用域错误。

最常见的触发同类报错的错误配置 #

很多开发者会图方便在全局钩子中写这类代码：

# 错误示例：示例级钩子作用域下直接调用类层级的name方法
config.before(:each) do
  Rails.logger.info "正在执行 #{described_class.name} 的测试用例"
end

这类写法在部分RSpec版本中，就会直接触发最初的name is not available from within an example报错。

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