testing - 查找破坏测试的提交，而无需在每次提交时运行每个测试

Question

我正在尝试找到可以解决以下问题的工具：

我们的整个测试套件需要数小时才能运行，这通常使得找出哪个提交破坏了特定测试变得困难或至少非常耗时，因为在两次测试运行之间可能有 50 到 200 次提交。在任何给定时间，只有极少数损坏的测试，因此与运行整个测试套件相比，仅重新运行损坏的测试非常快。

是否有一个工具，例如持续集成服务器，可以在测试正常的最后一个修订版和测试不正常的第一个修订版之间重新运行失败的测试并进行几个修订，从而自动找出具体的提交测试从成功切换到失败。

例如：

测试 A 和 B 在修订版 100 中正常。测试 A 和 B 在修订版 200 中损坏。

该工具现在应该运行版本 150 的两个测试。然后，如果测试 A 被破坏并且测试 B 在版本 150 中正常，它可以继续检查测试 A 的版本 125 和测试 B 的版本 175，依此类推，直到每个测试失败可以通过一些特定的提交来解释。

对于一个单一的测试，我可能会用 git bisect 破解一些东西。但是对于多次失败的测试，这可能还不够，因为我们需要在两个方向上搜索许多修订。

score 4 · Accepted Answer

混帐

假设您的项目的 2.6.18 版本可以工作，但“master”的版本崩溃了。有时，找出这种回归原因的最佳方法是通过项目历史执行暴力搜索，以找到导致问题的特定提交。git bisect 命令可以帮助你做到这一点：[...]

本质上，您将两个修订标记为开始和结束并点击：

$ git bisect

然后运行测试并根据它是通过还是失败调用

$ git bisect good

或者

$ git bisect bad

分别。git 将进行二进制搜索，总是将剩余的修订减半。我想您可以轻松编写脚本。如果您使用的是svn，git 可以轻松导入整个存储库。

这不是一个答案，而是一个建议——只需测试每一个提交！今天，您可以轻松地集群持续集成服务器，使用服务器场测试所有提交并不难。