我在RSpec测试中有一个带有2000多个示例的Rails应用程序。毋庸置疑，这是一个大型应用程序，需要进行很多测试。此时运行这些测试的效率非常低，并且由于需要花费很长时间，因此在推动新版本之前，我们几乎不鼓励编写这些测试。我在自己的spec.opts文件中添加了--profile文件，以查找运行时间最长的示例，其中至少有10个示例平均需要运行10秒。在您的RSpec专家中这正常吗？ 10秒对于一个例子来说完全太长吗？我意识到，使用2,000个示例，将需要花费大量的时间来全面测试所有内容-但此时4个小时有点荒谬。
您看到运行时间最长的示例是什么样的时间？我该怎么做才能解决现有规格问题，从而找出瓶颈并加快速度。在这一点上，每分钟确实会有所帮助。
10秒对于任何单个测试来说都是很长的时间。我的直觉是您的规格目标同时运行单元测试和集成测试。这是项目落入的典型事物，在某个阶段，如果您想更快地生产更多，您将需要克服此技术债务。有很多策略可以帮助您实现这一目标...并且我将推荐一些我过去使用过的策略。
1。与集成测试分开的单元
我要做的第一件事是将单元与集成测试分开。您可以通过以下方式执行此操作：
理念是，您希望常规构建要快-否则人们不会太乐意经常运行它们。所以回到那个领域。让您的常规测试快速运行，并使用连续集成服务器运行更完整的版本。
集成测试是涉及外部依赖项（例如，数据库，WebService，队列，有些可能会争用FileSystem的测试）。单元测试仅测试要检查的特定代码项。它应该运行得很快（可能在45秒内达到9000），即大多数应在内存中运行。
2。将集成测试转换为单元测试
如果单元测试的大部分小于集成测试套件，则存在问题。这意味着不一致将更容易出现。因此，从这里开始创建更多的单元测试以替换集成测试。您可以在此过程中提供帮助的事情是：
一旦您有适当的单元测试来替换集成测试，请删除集成测试。重复测试只会使维护工作更糟。
3。不要使用灯具
固定装置是邪恶的。请改用工厂（机械师或factorybot）。这些系统可以构建更具适应性的数据图，更重要的是，它们可以构建供您使用的内存对象，而不是从外部数据源加载事物。
4。添加检查以停止单元测试成为集成测试
现在您已进行了更快的测试，现在有时间进行检查以阻止这种情况再次发生。
有些库在尝试访问数据库（UnitRecord）时会猴子修补活动记录以引发错误。
您还可以尝试配对和TDD，这可以帮助您的团队编写更快的测试，因为：
5。使用其他图书馆来解决问题
[有人提到spork（加快在rails3下测试套件的加载时间），hydra / parallel_tests-以并行方式（跨多个内核）运行单元测试。
这应该最后使用。您真正的问题一直在步骤1、2、3中解决。您将可以更好地发挥其他基础设施的作用。
有关改善测试套件性能的出色食谱，请查看Grease Your Suite演示文稿。
您可以使用Spork。它支持2.3.x，
每个示例10秒似乎很长的时间。我从未见过花费超过一秒钟的规格，而大多数花费更少。您正在测试网络连接吗？数据库写？文件系统写入？