在测试Rails时管理模型关联的复杂性

时间:2014-06-05 22:02:14

标签: ruby-on-rails testing design-patterns rails-activerecord

在最近的几个项目中,我认为模型关联可以非常快速地变得非常复杂。由于这种复杂性,感觉测试比它需要的更难。例如,我需要为测试创建模型A的实例。很多时候,它看起来像这样(这取自我现在正在处理的应用程序):

  • 创建模型A,但模型A依赖于B.
  • 模型B依赖于模型C
  • 模型C依赖于D,E和F.具体来说,它需要附加6个F才能被认为是有效的。
  • 模型D,E和F可能有两个依赖关系。

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

Stubs可能会有所帮助,但我觉得这个要求代表了它的核心建模的错误。

是否有任何模式旨在帮助这样的依赖?我一直在考虑的一件事是根据上下文使大部分验证成为条件。控制器将模型保存在该验证上下文中,但这样我的测试套件就可以创建对象,否则这些对象将无法使用#34;在实时应用程序或完整集成测试套件中。问题在于我觉得它为了测试而改变了我的代码库,我认为这通常是一个坏主意。

1 个答案:

答案 0 :(得分:0)

和我一样,我不想在我的应用程序中使用特定于测试的代码。我还希望始终进行验证,因为如果我不知道哪些测试可能会构建无效数据,从而在不应该的情况下通过?

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

  • 我相信您已经使数据库中的所有内容成为应该存在的种子,即不需要比部署更频繁地进行更改的模型实例。

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

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

    (Haven没有测试过,但我相信意图很明确。)

  • 如果你有时需要重复使用B并且有时会创建一个新的,显然你有时需要编写一些代码。最明智的做法可能是在测试中创建一个B并将其传递给应该重复使用的A而不是那些不应该使用的A.