我使用Git进行版本控制,使用QUnit进行单元测试。有时我发现我的软件中存在过去版本中没有的错误。我很容易为这个bug编写一个单元测试。
鉴于单元测试,我可以轻松地通过所有过去的提交并使用该单元测试来测试构建,以便我可以确定哪个提交导致了破坏吗?
答案 0 :(得分:11)
您描述了git bisect
的工作。 Git Book有a good tutorial。
在您的问题条款中也存在一些混淆:当使用测试来防止重新引入先前修复的错误或错误提交错误时,它被称为回归测试 ,而不是单元测试。后一个测试纯粹是测试一个给定的小代码单元是否有效,并且受到严格的时间限制(TDD人员每天运行单元测试几十次)。对于大型项目,您通常需要比单元测试更长的回归测试,因此您可能希望清除类别。
答案 1 :(得分:10)
使用git bisect
,请参阅this page。
由于您正在测试JavaScript,因此您可能需要手动运行测试并根据需要运行git bisect good
和git bisect bad
。但是,如果您可以从命令行运行单元测试,那么您可以使用git bisect run
让Git重复执行测试并自动跟踪错误提交:
$ git bisect run my-script.sh
第一次看到它时,那是纯粹的魔法! : - )
答案 2 :(得分:3)
Git有一个命令可以完全按照你的意愿行事,git bisect
通过二进制搜索查找引入错误的更改
在您的情况下,您希望将其用作git bisect run /path/to/script
,它将自动测试提交并对每次提交执行检查以查找错误的提交。
请注意,如果当前源代码良好,脚本(上例中的my_script)应该以代码0退出,如果当前源代码不好,则退出时使用1到127(含)之间的代码,但125除外
任何其他退出代码都将中止bisect进程。应该注意的是,通过“exit(-1)”终止的程序会留下$? = 255,(参见exit(3)手册页),因为该值被“& 0377”切断。
当无法测试当前源代码时,应使用特殊退出代码125。如果脚本以此代码退出,则将跳过当前修订(请参阅上面的git bisect)。选择125作为用于此目的的最高敏感值,因为POSIX shell使用126和127来指示特定的错误状态(127表示未找到命令,126表示找到命令但不可执行---这些详细信息无所谓,因为它们是脚本中的正常错误,就“bisect run”而言。
因此,您的脚本将编译您的源代码,运行您的单元测试套件,然后提供相应的退出代码。 bisect manpage的示例部分很好地涵盖了这一点(包括破坏的构建,合并修补程序提交等)。
答案 3 :(得分:1)
是的,这称为git bisect
,最初是在git中引入的。
原理:
c1
; c1
之后抓住提交,将其称为c2
; git bisect start c2 c1
。如果您知道失败的位置,您甚至可以将bisect限制为子路径,和如果您有一个可以非交互式运行测试的脚本,请使用git bisect run
。