Rails/Rspec - 为委托方法编写规范(allow_nil选项)

Question

鉴于以下代码:

(1)您如何编写规范来测试:allow_nil => false选项？

(2)是否值得编写规范进行测试？

class Event < ActiveRecord::Base
  belongs_to :league

  delegate :name, :to => :league, :prefix => true, :allow_nil => false
end

describe Event do

  context 'when delegating methods to league object' do
    it { should respond_to(:league_name) }
  end

end

如果你能扩展应该这样做,那将是很好的:

it { should delegate(:name).to(:league).with_options(:prefix => true, :allow_nil => false) }

Answer 1

根据delegaterails模块的文档:

如果委托对象为nil,则引发异常,无论nil是否响应委托方法,都会发生这种情况.您可以使用:allow_nil选项获取nil.

我将创建一个event带有nil league或set 的Event对象event.league = nil,然后尝试调用event.name,并检查它是否引发异常,因为这allow_nil是假当它是假的(这也是默认值).我知道rspec有这个用于异常测试的习惯用法:

lambda{dangerous_operation}.should raise_exception(optional_exception_class)

我不确定是否应该有这个结构,尽管有一些文章,有点老,关于如何在shoulda中获得这种行为.

我认为这是值得测试的,如果这个类的用户可以预期或假设会发生的行为 - 我认为在这种情况下可能是正确的.我不会延伸应该测试"应该委托",因为这似乎更依赖于实现:你真的说你的事件应该引发异常,如果你尝试在#name没有联盟时打电话.事件的用户对于如何实现这一点并不重要.我甚至会走这么远,如果你想坚持并记下此行为,测试Event#name具有相同的语义League#name,不提任何东西delegate,因为这是一个行为为中心的方法.

根据代码的行为而不是如何构建代码来构建测试 - 以这种方式测试对于那些偶然进入测试的人来说是更好的文档,因为他们对"为什么我的事件会抛出？"这个问题更感兴趣.或"什么可能导致事件抛出？" 比"这个活动委托吗？".

您可以通过想象如果以Event用户不关心的方式更改代码,可能会发生什么样的故障,从而突出显示这种情况.如果他们不关心它,那么当你改变它时测试不应该破坏.例如,如果你想通过编写一个#name首先记录或递增计数器然后委托给一个计数器的函数来自己处理委托league怎么办？通过测试异常提高的行为,你免受这种变化,但通过测试,如果事件是一个委托,你会打破测试时,你做出这个改变-所以你的测试没有看什么真正对重要打电话给#name.

无论如何,这只是肥皂盒谈话.tl; dr:测试它是否是某人可能依赖的行为.任何未经测试的东西都是Shroedinger的猫:破碎而不是同时破碎.说实话,大部分时间都可以这样:无论你是想对系统应该如何表现,还是仅仅让它成为"未指明的行为",这是一个品味问题.

Answer 2

匹配器现在应该检查允许 nil选项。

class Account
  delegate :name, to: :league, allow_nil: true
end

# RSpec
describe Account do
  it { should delegate_method(:name).to(:league).allow_nil }
end