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

Question

我目前正在寻找一个庞大的Rails测试套件.我无法了解具体细节,但整个套件的运行时间(单元/功能/某些集成)可以运行5分钟.

我们完全依赖于固定装置,我们不会像我们应该那样嘲笑和抄袭.

我们接下来的几个冲刺将完全集中在测试套件上,既可以提高覆盖率,也可以编写更好的测试,最重要的是编写更有效的测试.

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

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

谢谢!

Answer 1

奥列格的答案很棒,但让我提供一个使用两者的人的观点.

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

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

我会说,根据您的测试套件的大小,您确实需要关注持续集成,以便将您的开发扩展到更高的水平.无论你加快多少速度,开发人员都需要等待很长时间.也许看看自动测试也可以在个人层面上提供帮助.但最终CI将允许您在不牺牲开发人员敏捷性的情况下维持测试规则.

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

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

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

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

另外,让我推荐Jay Fields的博客,以获得非常好的实用测试建议.我最喜欢Jay的博客是他总是承认测试是针对特定项目的,而对一个项目有用的并不一定适用于另一个项目.他缺乏教条,长期以来都是实用主义.

Answer 2

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

比赛时间:

• 难以维持关系(特别是多对多);
• 由于更多数据库命中,测试套件运行时通常较慢;
• 测试对模式的变化非常敏感.

工厂:

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

因此,工厂似乎是一个很好的方式.我看到的唯一可能的缺点是:

• 你从固定装置迁移的时间;
• 保持一套理智的场景可能需要一些努力.