事后单元测试

Question

我用Git做版本控制，用QUnit做单元测试。有时我发现我的软件中有一个以前的版本中没有的bug。对我来说，专门为这个bug编写单元测试是很容易的。

有了那个单元测试，我可以很容易地检查我过去的所有提交，并用那个单元测试来测试构建，这样我就可以确定是哪个提交导致了破坏吗？

Answer 1

请参考this page，使用git bisect。

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

$ git bisect run my-script.sh

这是纯粹的魔法，你第一次看到它！:-)

Answer 2

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

在你的问题中也有一些混淆:当一个测试被用来防止以前修复的错误的重新引入或buggy提交的一分为二时，它被称为回归测试，而不是单元测试。后一个测试纯粹是测试给定的小代码单元是否正常工作，并且受到大量的时间限制(TDD人员一天内运行几十次单元测试)。对于大型项目，您通常有比单元测试长得多的回归测试，因此您可能希望清理类别。

Answer 3

Git有一个命令可以做你想做的事情，git bisect

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

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

请注意，如果当前源代码是好的，则脚本(上例中的my_script)应以代码0退出，如果当前源代码不好，则脚本应以1到127 (含)之间的代码退出，125除外。

任何其他退出代码都将中止二等分进程。应该注意的是，通过“$(-1)”终止的程序会留下$？= 255 (参见exit(3)手册页)，因为该值是用"& 0377“截断的。

当当前源代码无法测试时，应使用特殊退出代码125。如果脚本带着这段代码退出，当前版本将被跳过(参见上面的git二分跳过)。出于此目的，125被选为最高可感知的值，因为POSIX shell使用126和127来表示特定的错误状态(127表示未找到命令，126表示已找到但不可执行的命令-这些细节无关紧要，因为就“二等分运行”而言，它们是脚本中的正常错误)。

因此，您的脚本将编译源代码，运行单元测试套件，然后给出相应的退出代码。bisect manpage中的示例部分很好地介绍了这一点(包括损坏的构建、合并热修复提交等)。