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

Question

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

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

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

例如:

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

该工具现在应该运行版本为 150 的两个测试。 那么如果例如测试 A 在修订版 150 中被破坏而测试 B 正常，它可以继续检查修订版 125 中的测试 A 和修订版 175 中的测试 B，依此类推，直到每个失败的测试都可以通过某个特定的提交来解释。

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

Answer 1

git

你在使用 git或 mercurial (参见:What is Mercurial bisect good for?)？

Suppose version 2.6.18 of your project worked, but the version at "master" crashes. Sometimes the best way to find the cause of such a regression is to perform a brute-force search through the project's history to find the particular commit that caused the problem. The git bisect command can help you do this:[...]

发件人:Finding Issues - Git Bisect .

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

$ git bisect

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

$ git bisect good

或

$ git bisect bad

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

一次构建一个版本

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