ruby-on-rails - 测试 Rails 时管理模型关联的复杂性

Question

在最近的几个项目中，我觉得模型关联会变得非常复杂且非常快。由于这种复杂性，感觉测试比它需要的要难得多。例如，我需要为测试创建模型 A 的实例。很多时候，它看起来像这样(这是从我现在正在开发的应用程序中获取的):

• 创建模型 A，但模型 A 依赖于 B。
• 模型 B 依赖于模型 C
• 模型 C 依赖于 D、E 和 F。具体来说，它需要附加 6 个 F 才能被视为有效。
• 模型 D、E 和 F 可能有一个或两个依赖项。

最后，创建了A。我在这个应用程序上使用工厂，这有点帮助，但当我需要满足如此多的验证以创建一个与任何验证无关的简单模型时，它仍然感觉太多了。

stub 可能会有所帮助，但我觉得该要求代表其核心建模存在问题。

是否有任何旨在帮助解决此类依赖关系的模式？我一直在考虑的一件事是根据上下文使大部分验证有条件。 Controller 会将模型保存在该验证上下文中，但这让我的测试套件可以创建在实时应用程序或完整集成测试套件中“无效”的对象。这样做的问题是，我觉得它为了测试而改变了我的代码库，我认为这通常是个坏主意。

Answer 1

像您一样，我宁愿在我的应用程序中没有特定于测试的代码。我也宁愿一直进行验证，因为如果我不这样做，谁知道什么测试可能会构造无效数据并因此在不应该通过的时候通过？

但是当测试快速运行时会更好。所以:

• 我相信您已经将数据库中的所有内容都作为种子，即不需要比部署更频繁地更改的模型实例。

• 如果您正在使用 factory_girl，而不是仅仅定义关联并让 factory_girl 每次都创建它们，您可以让您的工厂重用依赖项:

  factory :a do
    before :create do |a, _|
      a.b ||= B.first || FactoryGirl.create(:b)
    end
  end
  

  (尚未测试，但我相信意图很明确。)

• 如果您有时需要重用 B 有时需要创建新的 B，显然有时您必须编写一些代码。最明智的做法可能是在测试中创建一个 B，并将其传递给应该重用它的 A，而不是传递给不重用它的 A。