使用git bisect和mvn测试自动发现错误

当您发现几个星期（或多个版本）可以正常工作的功能中的错误时，您是否知道这种感觉？ 太糟糕了，我们没有任何自动化的测试，以前没事的现在坏了。 让我们以这个简单的存储库为例：

先写测试

我们注意到，某些特殊功能在1.0版中可以，但在1.1版中已被破坏。 我们要做的第一件事是什么？ 当然， 编写一个测试用例以确保此错误一旦修复，就永远不会回来！ 为发现的每个错误编写（失败）测试有很多优点：

1. 它记录了错误并证明已修复
2. 非显而易见的解决方法和解决方案将不会被删除（“为什么他在这里检查null ？！这不可能，我们简化一下”）
3. 您甚至可以在旧版代码库中逐步提高总体代码覆盖率。

因此，您有一个失败的测试用例。 但是，即使使用隔离测试，也无法可靠地找出问题所在。 如果我们只能找到一个破坏了测试的提交，则假定提交很小且专注。 但是，如果我们现在提交测试并签入一个较旧的版本来运行它–它尚不存在。 毕竟，测试只是现在才对代码库做出了解释，如果它在第一个修订版中就存在，我们将完全不会遇到问题：

互动式基地

也许不是在版本1.1之后提交测试（我们知道它已损坏），而是应该打补丁或隐藏该测试？ 这样，我们可以遍历1.0到1.1之间的所有修订，取消隐藏或通过测试应用补丁并运行它。 希望您同意这远非完美。 第一个技巧是使用交互式基准，以便及时将失败的测试用例的提交移回原处。 但是，我们不想对master分支进行重新设置基准，因此我们制作了一个临时副本并将其重新设置为基准：

$ git checkout -b tmp
Switched to a new branch 'tmp'
 
$ git rebase -i 1.0 tmp
Successfully rebased and updated refs/heads/tmp.

交互式rebase会要求我们在继续操作之前重新排列提交，只需将带有测试用例的提交从最后位置移到第一位置：

pick 10dbcc9 Feature 2
pick f4cf58a Feature 3
pick 8287434 Feature 4
pick e79d56f Feature 5
pick 50614b6 Feature 6
pick 21ae08f Feature 7
pick 1e5b5a5 Feature 8
pick f703abf Feature 9
pick 686d7a9 Feature 10
pick b5b5cf1 Feature 11
pick 8e58593 Feature 12
pick 3ab419a Feature 13
pick 0e769a0 Feature 14
pick 8bfdbea Feature 15
pick 0a95b7f Feature 16
pick 4622cbc Feature 17
pick 757c4eb Feature 18
pick 3d94d7e Feature 19
pick da69f6a Feature 20
pick 733bd17 Test for bug #123

现在我们的存储库应该看起来像这样：

git bisect

最重要的是，我们的测试用例现在是在1.0版之后发布的（已知是好的）。 我们要做的就是一个接一个地检查所有修订并运行此测试。 停！ 如果您很聪明（或懒惰），那么您将从中间的提交开始，如果这个提交被破坏了，则以相同的方式进行上半部分–否则进行下半部分。 这有点像二进制搜索。 但是，跟踪哪个提交最后一次看是好是坏，以及在中间手动检查修订是否相当麻烦。 幸运的是，git可以使用git bisect命令为我们做到这一点。 在开始平分之后，原则上我们指定最后一次已知的正确提交和第一次已知的错误提交。 Git将在两者之间检入修订，并询问我们是好是坏，继续直到找到确切的提交中断代码为止。 在我们的例子中，我们仅运行mvn test并根据其结果进行操作：

$ git bisect start
 
$ git bisect good 1.0
 
$ git bisect bad tmp
Bisecting: 9 revisions left to test after this (roughly 3 steps)
[13ed8405beb387ec86874d951cf630de2c4fd927] Feature 10
 
$ mvn test -Dcom.nurkiewicz.BugTest
...
[INFO] BUILD SUCCESS
 
$ git bisect good
Bisecting: 4 revisions left to test after this (roughly 2 steps)
[b9e610428b61ba1436219edbaa1c5c435a1907ae] Feature 15
 
$ mvn test -Dcom.nurkiewicz.BugTest
...
[INFO] BUILD SUCCESS
 
$ git bisect good
Bisecting: 2 revisions left to test after this (roughly 1 step)
[e8a5ddd4dea219d826a15f7a085e412c29333b10] Feature 17
 
$ mvn test -Dcom.nurkiewicz.BugTest
...
[INFO] BUILD FAILURE
 
$ git bisect bad
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[6d974faffa042781a098914a80d962953a492cb5] Feature 16
 
$ mvn test -Dcom.nurkiewicz.BugTest
...
[INFO] BUILD SUCCESS
 
$ git bisect good
e8a5ddd4dea219d826a15f7a085e412c29333b10 is the first bad commit
commit e8a5ddd4dea219d826a15f7a085e412c29333b10
Author: Tomasz Nurkiewicz
Date:   Wed Mar 19 19:43:40 2014 +0100
 
    Feature 17
 
:100644 100644 469c856b4ede8 90d6b2233832 M      SomeFile.java

看看我们如何在两者之间执行测试用例时反复调用git good / bad ？ 另请注意，测试提交数量减少的速度。 您可能会认为这是整洁且快速的（对数时间！），但实际上我们可以快得多。 git bisect有一个隐藏的gem，称为run模式。 我们可以提供一个脚本来告诉给定的修订是好是坏，而不是依靠每次迭代后用户的手动回答。 按照惯例，如果此脚本以代码0退出，则表示成功，而其他任何退出代码均表示错误。 幸运的是， mvn脚本遵循此约定，因此我们可以简单地执行git bisect mvn test -Dcom.nurkiewicz.BugTest ，坐下来放松一下：

$ git bisect start
 
$ git bisect good 1.0
 
$ git bisect bad tmp
Bisecting: 9 revisions left to test after this (roughly 3 steps)
[13ed8405beb387ec86874d951cf630de2c4fd927] Feature 10
 
$ git bisect run mvn test -Dcom.nurkiewicz.BugTest
running mvn test -Dcom.nurkiewicz.BugTest
...
[INFO] BUILD SUCCESS
...
Bisecting: 4 revisions left to test after this (roughly 2 steps)
[b9e610428b61ba1436219edbaa1c5c435a1907ae] Feature 15
running mvn test -Dcom.nurkiewicz.BugTest
...
[INFO] BUILD SUCCESS
...
Bisecting: 2 revisions left to test after this (roughly 1 step)
[e8a5ddd4dea219d826a15f7a085e412c29333b10] Feature 17
running mvn test -Dcom.nurkiewicz.BugTest
...
[INFO] BUILD FAILURE
...
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[6d974faffa042781a098914a80d962953a492cb5] Feature 16
running mvn test -Dcom.nurkiewicz.BugTest
...
[INFO] BUILD SUCCESS
...
e8a5ddd4dea219d826a15f7a085e412c29333b10 is the first bad commit
commit e8a5ddd4dea219d826a15f7a085e412c29333b10
Author: Tomasz Nurkiewicz
Date:   Wed Mar 19 19:43:40 2014 +0100
 
    Feature 17
 
:100644 100644 469c856b4ede8 90d6b2233832 M      SomeFile.java
bisect run success

上面的程序是非交互式的，并且是完全自动化的。 git，经过几次迭代，精确地指出了哪个提交是第一个破坏测试的提交。 我们可以运行所有测试，但是没有意义，因为我们知道只有一项测试失败了。 当然，您可以使用任何其他命令而不是mvn 。 您甚至可以用您选择的任何JVM语言编写一些简单的脚本（使用System.exit () ）。 git bisect与交互式重定基准相结合，是查找回归和错误的绝佳工具。 他们还促进自动化测试和总体自动化。

翻译自: https://www.javacodegeeks.com/2014/03/automated-bug-finding-with-git-bisect-and-mvn-test.html