ruby-on-rails - 在 Rails 测试套件中使用工厂的优点和缺点？

Question

我目前正在研究一个庞大的 Rails 测试套件。我无法详细说明，但整个套件(单元/功能/某些集成)的运行时间可能超过 5 分钟。

我们完全依赖固定装置并且我们没有像我们应该的那样 mock 和 stub 。

我们接下来的几个冲刺将完全专注于测试套件，既提高覆盖率，编写更好的测试，最重要的是编写更高效的测试。

因此，除了在我们的测试中进行更多的模拟和 stub 之外，我们正在考虑用最有可能的 Factory Girl 替换我们的固定装置。我看到很多快乐的人在做类似的情况，但一直无法找到关于搬到工厂的任何缺点的好资源。当使用来自各种资源的基准时，我看到了一些较慢的基准，但无法找到明确的原因，为什么工厂是好的，这就是为什么你可能不想使用它们。

谁能告诉我为什么或为什么我不应该使用工厂？

谢谢!

Answer 1

Oleg 的回答很好，但让我提供一个同时使用这两种方法的人的观点。

Fixtures 在一段时间内一直是 Rails 社区的替罪羊。每个人都了解固定装置的缺点，但没有人真正拥护它们的优势。根据我的经验，工厂本身很容易变得和固定装置一样难以维护(这实际上取决于架构，但我离题了)。工厂的真正优势在于有选择性地更换基于夹具的痛苦。让我们来谈谈几个细节。

第一个问题是性能。如果您可以在不访问数据库的情况下测试大部分应用程序，那么您会看到显着的加速，但对于大多数应用程序，我认为在不完全访问数据库的情况下进行测试是不明智的。在某些时候，您想测试整个堆栈。每次模拟或 stub 时，您都在假设一个可能包含细微错误的接口(interface)。因此，假设您需要在相当大比例的测试中访问数据库，事务性固定装置(您正在使用事务性固定装置，对吗？)可能比为每个测试实例化整个环境快得多。

我会说，根据您真正需要关注的测试套件的大小 Continuous Integration将您的开发扩展到一个新的水平。无论您将它们的速度提高多少，开发人员仍然需要等待很长时间。也许看看autotest以及在个人层面上提供帮助。但最终 CI 将允许您在不牺牲开发人员敏捷性的情况下保持测试纪律。

固定装置真正发挥作用的地方是功能/集成测试。我的看法是，fixtures 应该为要测试的应用程序设置一个健康的基本状态。大多数单元测试并不真正需要这个。您可以使用工厂获得非常好的单位覆盖率。然而，当涉及到功能测试时，任何给定的页面都可能会遇到几十个模型。我不想在每次测试中都设置所有这些东西。随着我构建越来越复杂的场景，我越来越接近于重新创建一个全局数据状态，这正是 fixture 最初设计的目的。

我持有的一个有争议的信念是，在其他条件相同的情况下，我更喜欢一次功能测试而不是 20 个单元测试(使用 Rails 的说法)。为什么？因为功能测试证明发送给用户的最终结果是正确的。单元测试非常适合了解功能的细微差别，但在一天结束时，您仍然可能会在界面上出现错误，从而破坏整个站点。功能测试让我有信心在不实际加载浏览器页面的情况下进行部署。我知道我可以将所有东西都 stub 并测试两个接口(interface)并获得相同的覆盖率，但如果我可以在一个简单的测试中测试整个堆栈，而牺牲一点 CPU，我宁愿这样做。

那么我对固定装置的最佳实践是什么？

• 为每个模型设置少量模型以涵盖最广泛的数据类别
• 在添加跨多个模型和 Controller 的主要新功能时，添加一些新装置来表示主要状态
• 除了添加/删除字段外，避免编辑旧固定装置
• 使用工厂实现更小/更本地化的变体
• 使用工厂来测试分页或其他只需要少数测试的批量创建

另外，让我推荐Jay Fields' blog真正好的实用测试建议。关于 Jay 的博客，我最喜欢的一点是他总是承认测试是非常特定于项目的，适用于一个项目的东西不一定适用于另一个项目。他缺乏教条，却很注重实用主义。