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

Question

我目前正在寻找一个庞大的Rails测试套件。我无法了解具体内容，但整个套件的运行时间（单元/功能/某些集成）可能会持续5分钟。

我们完全依赖于固定装置，我们不应该像我们应该那样嘲笑和诅咒。

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

因此，除了在我们的测试中更多的嘲弄和顽固，我们正在考虑用最可能的工厂女孩​​替换我们的灯具。我看到很多快乐的人都在做类似的情况但却找不到有关搬到工厂的任何缺点的好资源。我在使用各种资源的基准测试时看到了一些较慢的基准测试，但是找不到确定工厂为什么好的原因，这就是为什么你可能不想使用它们。

有人可以告诉我为什么或为什么我不应该使用工厂？

谢谢！

Answer 1

奥列格的答案很棒，但让我提供使用两者的人的观点。

一段时间以来，Fixtures一直是Rails社区的鞭打男孩。每个人都了解灯具的缺点，但没有人真正支持他们的优势。根据我的经验，工厂本身很容易变得像固定装置一样难以维护（它实际上取决于架构，但我离题了）。工厂的真正优势在于选择性地替代基于夹具的疼痛。我们来谈谈几个细节。

第一个问题是表现。如果您可以测试大部分应用程序而不需要访问数据库，那么您将看到显着的加速，但对于大多数应用程序，我认为在没有完全访问数据库的情况下进行测试是不明智的。在某些时候，你想测试整个堆栈。每次你模拟或存根时，你都会对可能包含细微错误的界面做出假设。因此，假设您需要在一定比例的测试中访问数据库，事务性工具（您 使用事务性工具吗？）可能比为每个测试实例化整个环境要快得多。

我会说，根据您的测试套件的大小，您真正需要关注Continuous Integration以将您的开发扩展到更高级别。无论你加快多少速度，开发人员都需要等待很长时间。也许看autotest也可以在个人层面上提供帮助。但最终CI将允许您在不牺牲开发人员敏捷性的情况下维持测试规则。

灯具真正发光的地方是功能/集成测试。我看待它的方式是，灯具应该为要测试的应用程序设置一个健康的基本状态。大多数单元测试并不需要这样。您可以使用工厂获得非常好的单位覆盖率。但是，在功能测试方面，任何给定的页面都可能会遇到数十种模型。我不想在每个测试中设置所有这些东西。当我构建更复杂的场景时，我越来越接近重新创建一个全局数据状态，它首先正好设计要做的事情。

我认为一个有争议的信念是，在其他条件相同的情况下，我更喜欢一个功能测试到20个单元测试（使用Rails用语）。为什么？因为功能测试证明发送给用户的最终结果是正确的。单元测试非常适合于获得功能的细微差别，但在一天结束时，您仍然可能在界面上出现打破整个站点的错误。功能测试使我有信心进行部署，而无需在浏览器中实际加载页面。我知道我可以将所有内容存根并测试两个接口并获得相同的覆盖率，但如果我可以在一个简单的测试中以一点CPU为代价测试整个堆栈，我宁愿这样做。

那么我对灯具的最佳做法是什么？

• 为每个模型设置一小部分以涵盖最广泛的数据类别
• 当添加一个跨越许多模型和控制器的主要新功能时，添加一些新的灯具来代表主要状态
• 除了添加/删除字段外，避免编辑旧的灯具
• 将工厂用于更小/更局部化的变体
• 使用工厂测试分页或其他只需要进行少量测试的大量创建

另外，我建议Jay Fields' blog提供非常好的实用测试建议。我最喜欢Jay的博客是他总是承认测试是针对特定项目的，而对一个项目有用的并不一定适用于另一个项目。他缺乏教条，长期以来都是实用主义。

Answer 2

对于良好的测试套件，在实体之间设置所有依赖关系可能存在一些问题。无论如何，它仍然比维护很多灯具容易得多。

灯具：

• 难以维持关系（特别是多对多）;
• 由于更多数据库命中，测试套件运行时通常较慢;
• 测试对架构的更改非常敏感。

工厂：

• 你将当前单元测试中未测试的所有内容存根;
• 您准备要使用工厂进行测试的实体。这就是工厂展示其真正优势的地方 - 设置新的测试用例很容易，因为你不需要为此维护大量的YAML文件;
• 你专注于测试。如果测试需要更改方案，则不要转变思维方式。只要存根合理且工厂很容易定制，你应该没问题。

因此，工厂似乎是一个很好的方式。我看到的唯一可能的缺点是：

• 您从灯具迁移的时间;
• 保持一套理智的场景可能需要一些努力。