在大型 Rails 应用程序中加速 RSpec 测试答案

【问题标题】：Speeding up RSpec tests in a large Rails application在大型 Rails 应用程序中加速 RSpec 测试
【发布时间】：2011-04-09 10:48:10
【问题描述】：

我有一个 Rails 应用程序，在我的 RSpec 测试中包含超过 2,000 个示例。不用说，这是一个大型应用程序，有很多需要测试的地方。在这一点上运行这些测试效率很低，而且因为它需要很长时间，我们几乎已经到了在推出新版本之前不鼓励编写它们的地步。我将 --profile 添加到我的 spec.opts 以查找运行时间最长的示例，其中至少有 10 个平均需要 10 秒才能运行。在你们的 RSpec 专家中这是正常的吗？对于一个例子来说，10 秒是否太长了？我意识到，对于 2,000 个示例，彻底测试所有内容将花费大量时间 - 但在这一点上 4 小时有点可笑。

对于运行时间最长的示例，您看到了什么样的时间？我可以做些什么来解决我现有的规范，以便找出瓶颈并帮助加快速度。在这一点上，每一分钟都非常有帮助。

【问题讨论】：

慢速测试是集成测试吗？他们在打分贝吗？如果是这样，数据库被重新加载的频率是多少，你可以模拟数据库吗？
您是否能够只运行与您正在处理的部分相关的部分规范，类似于 SeattleRB 的自动测试？你有可以运行所有测试的持续集成服务器吗？
请记住，所有事物都是相对的。我听说过“grrr，我们的测试套件永远需要”20 分钟……和 16-20 小时。这一切都在旁观者的眼中。给定测试的 10 秒通常意味着单元测试已成为如下所述的集成测试。
针对此类问题的建议：将perftools.rb 与您的测试框架一起使用，以了解您大部分时间都在使用什么。接听前 10 个电话并尝试消除/略读它们。然后重复，直到快乐。

标签： ruby-on-rails ruby unit-testing rspec bdd

【解决方案1】：

10 秒对于运行任何单个测试来说都是很长的时间。我的直觉是您的规范目标同时运行单元测试和集成测试。这是项目陷入的典型情况，并且在某个阶段，如果您想生产更多、更快的产品，您将需要克服这种技术债务。有许多策略可以帮助您做到这一点……我会推荐一些我过去使用过的策略。

1.将单元与集成测试分开

我要做的第一件事是将单元与集成测试分开。您可以通过以下方式做到这一点：

移动它们（到 spec 目录下的单独文件夹中） - 并修改 rake 目标
标记它们（rspec 允许您标记测试）

理念是，您希望您的常规构建快速 - 否则人们不会很乐意经常运行它们。所以回到那个领域。让您的常规测试快速运行，并使用持续集成服务器运行更完整的构建。

集成测试是一种涉及外部依赖项的测试（例如数据库、WebService、队列，有些人认为是文件系统）。单元测试只测试您要检查的特定代码项。它应该运行得很快（45 秒内可以运行 9000 次），即它的大部分应该在内存中运行。

2。将集成测试转换为单元测试

如果您的大部分单元测试小于集成测试套件，那么您就有问题了。这意味着不一致将更容易出现。所以从这里开始，开始创建更多的单元测试来代替集成测试。在此过程中您可以做的事情有：

使用模拟框架而不是真实资源。 Rspec 有一个内置的模拟框架。
在您的单元测试套件上运行 rcov。用它来衡量你的单元测试套件有多彻底。

一旦您有适当的单元测试来替换集成测试 - 删除集成测试。重复测试只会让维护变得更糟。

3.不要使用固定装置

固定装置是邪恶的。改用工厂（机械师或工厂机器人）。这些系统可以构建更具适应性的数据图，更重要的是，它们可以构建您可以使用的内存对象，而不是从外部数据源加载内容。

4.添加检查以阻止单元测试成为集成测试

现在您已经进行了更快的测试，是时候进行检查以阻止这种情况再次发生。

有些库会在尝试访问数据库 (UnitRecord) 时对活动记录进行猴子补丁以引发错误。

您还可以尝试配对和 TDD，这可以帮助您的团队编写更快的测试，因为：

有人在检查 - 所以没有人会偷懒
正确的 TDD 需要快速反馈。缓慢的测试只会让整个事情变得痛苦。

5.使用其他库来解决问题

有人提到 spork（加快 rails3 下测试套件的加载时间）、hydra/parallel_tests - 并行运行单元测试（跨多个内核）。

这可能应该最后使用。您真正的问题一直出现在第 1、2、3 步中。解决这个问题，您将能够更好地部署额外的基础设施。

【讨论】：

很好的答案。确实没有任何高级工具可以帮助快速运行糟糕的测试。所以试着只写好的。
我不同意你不应该使用固定装置的第三点。如果使用得当，它们比工厂更快，因为您不必创建对象。您的数据就在那里，您不必为每个测试用例创建它。
关于工厂更快的说法是个笑话，对吧？
通过选择性地避开工厂女孩来加快测试速度 - robots.thoughtbot.com/…

【解决方案2】：

有关提高测试套件性能的精彩食谱，请查看Grease Your Suite 演示文稿。

他记录了通过使用以下技术将测试套件运行时间提高了 45 倍：

【讨论】：

我喜欢链接，但不喜欢演示文稿。某人演讲的索引卡是演讲者填写演讲内容的提示。
此演示文稿不再播放。 fast_context 加速多个 shoulda 块。 quickerclip（那个链接也死了）显然加速了回形针。 Hydra 不推荐用于 parallel_tests 和 Gorgon。 bootsnap 对文件系统进行了调整，现在包含在 Rails 中。 Ruby 的最新版本改进了分配和 GC。

【解决方案3】：

您可以使用 Spork。它支持 2.3.x ，

https://github.com/sporkrb/spork

或 ./script/spec_server 可能适用于 2.x

您还可以编辑数据库配置（这实际上加快了数据库查询等），这也将提高测试性能。

【讨论】：

Spork 棒极了。它也可以在 Rails 3 上运行，但需要一点黑客攻击。但是，Spork on Rails 3 需要注意的一件事是，它似乎无法识别控制器中的更改，因此您需要每隔一段时间重新启动它。但不管怎样，Spork 真的很棒，测试的速度提升非常显着。
Spork 仅用于加速启动，不用于测试。所以有很多规格，优势是微不足道的。
与上面的 cmets spork 不同，可以使用 railscast railscasts.com/episodes/285-spork 加速测试和启动。在一个非常大的应用程序上大幅改进了我的 rspec 测试套件。（从 192 秒减少到 10 秒！）

【解决方案4】：

每个示例 10 秒似乎很长。我从未见过花费超过一秒钟的规范，而且大多数花费的时间要少得多。你在测试网络连接吗？数据库写入？文件系统写入？

尽可能多地使用模拟和存根 - 它们比编写访问数据库的代码快很多。不幸的是，模拟和存根也需要更多的时间来编写（并且更难正确执行）。您必须平衡编写测试所花费的时间与运行测试所花费的时间。

我赞同Andrew Grimm 关于研究 CI 系统的评论，该系统可能允许您并行化您的测试套件。对于这么大的东西，它可能是唯一可行的解决方案。

【讨论】：

是的，如果是 10 秒，我会分析它并查看瓶颈在哪里
我有一个庞大的项目，运行单个 rspec 测试需要将近 15-20 秒。

【解决方案5】：

如果您使用 ActiveRecord 模型，您还应该考虑 BCrypt 加密的成本。

您可以在这篇博文中了解更多信息：http://blog.syncopelabs.co.uk/2012/12/speed-up-rspec-test.html

【讨论】：

【解决方案6】：

faster_require gem 可能会对您有所帮助。除此之外，您唯一的方法是（就像您所做的那样）分析和优化，或使用 spork 或为您并行运行您的规范的东西。 http://ruby-toolbox.com/categories/distributed_testing.html

【讨论】：

【解决方案7】：

删除现有的测试套件。会非常有效。

【讨论】：