【发布时间】：2016-04-18 17:00:18
【问题描述】：
当我使用 git bisect 命令时，我只运行失败的测试 Java 程序的每个二等分点。但是，我看到许多与 git bisect 相关的教程都建议运行“make; make test”。有什么理由我应该在每一步运行所有测试吗？ 提前非常感谢。
【问题讨论】：
标签： java git git-bisect
【发布时间】：2016-04-18 17:00:18
【问题描述】：
我不得不说@bcmcfc 提到的条件是必要的，但不是充分的。供参考，他的条件是
- 所有测试在标记为良好的提交时通过
- 某些测试在标记为错误的提交时失败
我的问题是不知道在good 提交和bad 之间发生了什么。例如，在中间提交中是否发现并修复了另一个错误？可以想象，那个错误或其修复影响了这个错误。
另一个问题是历史中可能存在“脏”提交。我不知道你的使用模式，但有些人允许在功能分支上出现测试失败的提交。 bisect 可以登陆这些提交，如果您只运行您预计会失败的测试，您可能无法完全理解该提交中发生了什么，这可能会导致您在修复错误时误入歧途。甚至可能是在该功能分支中引入并修复了该错误，然后在另一个功能分支中再次引入以稍微不同的方式，这确实会混淆您修复它的努力。 p>
在我看来，这似乎是一句老话的一个例子，“理论上，理论和实践之间没有区别，但实际上是有区别的。”我每次都会运行每个测试。如果它们都通过了您的预期，那么您不应该觉得自己浪费了自己的努力，您应该充满自信，因为您知道自己知道发生了什么。
【讨论】：
-
嗨@Erick，非常感谢您富有洞察力的回答。它提供了一个非常完整的场景来了解如果我们不运行所有测试用例在调试中可能出现的问题。所以基本上我的理解是，如果我们想节省时间，我们可以只运行失败的测试用例。但这可能有助于也可能不会有助于完全理解该错误。另一方面，运行所有的测试用例会让我们更有信心充分理解这个 bug。
如果：
- 所有测试在标记为良好的提交时通过
- 某些测试在标记为错误的提交时失败
那么是的，只运行失败的测试来加速二分过程是安全的。您可以从测试结果中推断出其余测试应该通过的好提交和坏提交。
在任何情况下，您都可能会在修复相关错误后重新运行完整的测试套件，这涵盖了您的错误修复引入回归的情况。
【讨论】：
-
好的。这就说得通了。我也有同样的印象。非常感谢您的意见。