验尸单元测试

Question

我使用Git进行版本控制，使用QUnit进行单元测试。有时我发现我的软件中存在过去版本中没有的错误。我很容易为这个bug编写一个单元测试。

鉴于单元测试，我可以轻松地通过所有过去的提交并使用该单元测试来测试构建，以便我可以确定哪个提交导致了破坏吗？

Answer 1

您描述了git bisect的工作。 Git Book有a good tutorial。

在您的问题条款中也存在一些混淆：当使用测试来防止重新引入先前修复的错误或错误提交错误时，它被称为回归测试 ，而不是单元测试。后一个测试纯粹是测试一个给定的小代码单元是否有效，并且受到严格的时间限制（TDD人员每天运行单元测试几十次）。对于大型项目，您通常需要比单元测试更长的回归测试，因此您可能希望清除类别。

Answer 2

使用git bisect，请参阅this page。

由于您正在测试JavaScript，因此您可能需要手动运行测试并根据需要运行git bisect good和git bisect bad。但是，如果您可以从命令行运行单元测试，那么您可以使用git bisect run让Git重复执行测试并自动跟踪错误提交：

$ git bisect run my-script.sh

第一次看到它时，那是纯粹的魔法！ ： - ）

Answer 3

Git有一个命令可以完全按照你的意愿行事，git bisect

  

通过二进制搜索查找引入错误的更改

在您的情况下，您希望将其用作git bisect run /path/to/script，它将自动测试提交并对每次提交执行检查以查找错误的提交。

  

请注意，如果当前源代码良好，脚本（上例中的my_script）应该以代码0退出，如果当前源代码不好，则退出时使用1到127（含）之间的代码，但125除外

     

任何其他退出代码都将中止bisect进程。应该注意的是，通过“exit（-1）”终止的程序会留下$？ = 255，（参见exit（3）手册页），因为该值被“＆amp; 0377”切断。

     

当无法测试当前源代码时，应使用特殊退出代码125。如果脚本以此代码退出，则将跳过当前修订（请参阅上面的git bisect）。选择125作为用于此目的的最高敏感值，因为POSIX shell使用126和127来指示特定的错误状态（127表示未找到命令，126表示找到命令但不可执行---这些详细信息无所谓，因为它们是脚本中的正常错误，就“bisect run”而言。

因此，您的脚本将编译您的源代码，运行您的单元测试套件，然后提供相应的退出代码。 bisect manpage的示例部分很好地涵盖了这一点（包括破坏的构建，合并修补程序提交等）。

Answer 4

是的，这称为git bisect，最初是在git中引入的。

原理：

• 过去抓住你知道它有效的提交，让我们称之为c1;
• 在您知道失败的c1之后抓住提交，将其称为c2;
• git bisect start c2 c1。

如果您知道失败的位置，您甚至可以将bisect限制为子路径，和如果您有一个可以非交互式运行测试的脚本，请使用git bisect run。