RSpec 的最佳实践期望 raise_error答案

【问题标题】：Best Practices for RSpec expect raise_errorRSpec 的最佳实践期望 raise_error
【发布时间】：2017-11-14 20:59:48
【问题描述】：

我有一些 RSpec 的代码。我的（或不是我的）班级可以（或不）调用特定的异常。例如，类::Foo::Bar::TimeOutError。我要检查一下。

describe :describe_description do
  before :all do
    object = Class.new
    # method can be call Class::Foo::Bar::TimeOutError
    object.method
  end
  it :exception do
    expect {}.to_not raise_error Class::Foo::Bar::TimeOutError
  end
end

这段代码有效，但 RSpec 写了一个警告：

警告：使用expect { }.not_to raise_error(SpecificErrorClass) 有误报的风险，因为实际上任何其他错误都会导致期望通过，包括 Ruby 引发的错误（例如 NoMethodError、NameError 和 ArgumentError），这意味着您打算测试的代码甚至可能不会到达。而是考虑使用expect {}.not_to raise_error 或expect { }.to raise_error(DifferentSpecificErrorClass)。可以通过设置来抑制此消息：RSpec::Expectations.configuration.on_potential_false_positives = :nothing。

如何修复我的代码以使 RSpec 正常工作且不发出警告？

【问题讨论】：

当您预期某种错误时，传递特定的错误类很有用。没有明显的理由来测试不引发特定错误，因为您不希望在执行期间引发任何错误。 expect {}.to_not raise_error 可能是最好的解决方案。

标签： ruby exception rspec

【解决方案1】：

不，如果没有此警告，就无法在规范中应用 expect {}.to_not raise_error（这就是添加此警告的全部意义所在）。

这在逻辑上没有意义，因为您不需要显式检查未引发错误类型。

场景 1。代码成功执行（即完全没有错误）。那么通过测试本身就意味着没有Class::Foo::Bar::TimeOutError被抛出。

场景 2。引发另一种类型的错误。然后expect {}.to_not raise_error Class::Foo::Bar::TimeOutError 没有测试任何东西，它仍然只是通过，这会产生误报。

场景 3。如果您真的想使用它，请使用设置 on_potential_false_positives 进行抑制，然后测试将继续进行而不会发出警告。如果它通过了，那么这与使expect {}.to_not raise_error 多余的场景没有区别。

【讨论】：