ruby-on-rails - 在 TDD 中 stub 依赖有哪些好的方法？

Question

假设我正在用 Rspec 为 Rails 应用程序编写规范，并且我正在删除一些方法来减少规范中的依赖项数量:

# specs/account_statistics_spec.rb

describe AccountStatistics do
 it "gets the percentage of users that are active in an account" do
  account = Account.new()
  account.stub_chain(:users, :size).and_return(80)
  account.stub_chain(:users, :active, :size).and_return(20)

  stats = AccountStatistics.new(account)

  stats.percentage_active.should == 25
 end
end

现在即使 Account#users 和 User#active 方法没有在它们各自的类中定义，AccountStatistics 规范也可以通过。

有哪些好的方法可以捕捉 stub 方法可能无法实现的事实？是否应该留给集成测试来捕获未定义的方法？或者规范还应该在 stub 之前检查方法是否已定义？

如果有人可以链接到任何深入讨论 stubbing 和 mocking 的好书/演示文稿，那就太好了 :)

Answer 1

要解决您的具体问题，请查看 https://github.com/xaviershay/rspec-fire防止 stub 不存在的方法。

我认为这里更广泛的问题是您没有听取尝试编写此测试给您的反馈。难以编写的测试是测试主题设计不佳或您使用的测试技术不合适的好兆头。

如果这个类确实遵循 Demeter 法则(很难处理 ActiveModel 关系)，它会是什么样子？如果您提供一个测试替身对象而不是尝试模拟每个方法，您的测试会是什么样子？作为集成测试，您的测试会是什么样子？

我认为编写更好测试的最佳资源是查看被测试代码的设计。 http://www.poodr.com/可能是一个很好的资源。 http://www.martinfowler.com/bliki/TestDouble.html很好地概述了您在 http://blakesmith.me/2012/02/29/test-stubbing-as-an-antipattern.html 时可能不会考虑的测试替身争论为什么模拟可能完全是错误的工具。具体到 rspec http://betterspecs.org给出了一些好的规范可能看起来的结果。如果这些很难写，那就是一个很好的暗示，表明存在更广泛的问题。