如何测试在所有成员上调用方法的Rails模型类方法？

Question

在我的Rails 4项目中，我有一个模型EventGenerator，其实例方法generate（在数据库中创建了一些记录）和类方法generate_all这是由Rake任务调用的，看起来像这样：

def self.generate_all
  all.each(&:generate)
end

我可以想到几种测试方法（我使用RSpec 3和Fabrication）：

1. 不要打扰 - 要求测试太简单了。 DHH说"Don't aim for 100% coverage"。另一方面，这将由一个佣金任务调用，因此不会定期行使：我觉得这是一个很好的理由进行测试。
2. 在数据库中创建几个EventGenerator个实例，并使用any_instance.should_receive(:generate)作为断言 - 但RSpec 3 now recommends against this并需要一个软糖才能使其正常工作。这是一个个人的展示项目＆＃39;所以，如果可能的话，我希望一切都是最佳实践。另外（DHH除外）不应该仍然可以创建不接触数据库的快速模型规格吗？
3. 与2类似，但在没有触及数据库的情况下，将EventGenerator.all删除以返回某些实例。但对被测试的课程进行抄袭是不好的，对吧？而且很脆弱。
4. 不要担心单元测试，而是通过集成测试覆盖它：在数据库中创建几个生成器，运行方法，检查数据库中的更改/创建结果。
5. 更改实现：传入一组实例。但是，这只是将问题推回到一个层，以及一个测试驱动的变化，我看不出有利于设计。

由于我无法想到选项4的缺点，或许这就是答案，但我觉得我需要一些科学来支持它。

Answer 1

我实际上不会费心去测试它（所以你的1.），因为这个方法非常简单。

如果你想让它在测试范围内，但我建议你使用你的3.我的理由如下：

• 您对.generate_all的测试只需要声明方法#generate可以调用.all返回的每个实例。在这种情况下，.all的实际实现是无关紧要的，可以存根。
• 您对#generate的测试应断言该方法是正确的。如果这些测试断言此方法的正常运行，则.generate_all的测试不需要复制任何断言。
• 在#generate的测试中测试.generate_all的正常运行会导致测试之间出现不必要的依赖关系。