这个问题:How to test os.exit scenarios in Go (以及其中投票最高的答案)阐述了如何在 go 中测试 os.Exit()
场景。由于 os.Exit()
不容易被拦截,所以使用的方法是重新调用二进制文件并检查退出值。此方法在 slide 23 on this presentation 中进行了描述。作者:Andrew Gerrand(围棋团队的核心成员之一);代码很简单,全文转载如下。
相关的测试和主文件看起来像这样(注意这对文件单独是一个MVCE):
package foo
import (
"os"
"os/exec"
"testing"
)
func TestCrasher(t *testing.T) {
if os.Getenv("BE_CRASHER") == "1" {
Crasher() // This causes os.Exit(1) to be called
return
}
cmd := exec.Command(os.Args[0], "-test.run=TestCrasher")
cmd.Env = append(os.Environ(), "BE_CRASHER=1")
err := cmd.Run()
if e, ok := err.(*exec.ExitError); ok && !e.Success() {
fmt.Printf("Error is %v\n", e)
return
}
t.Fatalf("process ran with err %v, want exit status 1", err)
}
和
package foo
import (
"fmt"
"os"
)
// Coverage testing thinks (incorrectly) that the func below is
// never being called
func Crasher() {
fmt.Println("Going down in flames!")
os.Exit(1)
}
但是,这种方法似乎受到某些限制:
使用 goveralls/coveralls.io 进行覆盖率测试不起作用 - 参见示例 here (与上面相同的代码,但为方便起见放入 github)产生覆盖测试here ,即它不记录正在运行的测试功能。 请注意,您不需要这些链接来回答问题 - 上面的示例可以正常工作 - 它们只是为了展示如果您将上述内容放入 github 会发生什么,并一直通过 travis 到coveralls.io
重新运行测试二进制文件似乎很脆弱。
具体来说,根据要求,这里是覆盖失败的屏幕截图(而不是链接);红色阴影表示就 coveralls.io 而言,Crasher()
未被调用。
有没有办法解决这个问题?特别是第一点。
在 golang 级别,问题是这样的:
Goveralls 框架运行
go test -cover ...
,它会调用上面的测试。上面的测试调用
exec.Command/.Run
而操作系统参数中没有-cover
无条件地将
-cover
等放在参数列表中是没有吸引力的,因为它会在非覆盖测试中运行覆盖测试(作为子进程),并解析参数列表对于-cover
等的存在似乎是一个重型解决方案。即使我将
-cover
等放在参数列表中,我的理解是我会将两个覆盖输出写入同一个文件,这不会工作 - 这些需要以某种方式合并。我最接近的是this golang issue .
总结
我所追求的是一种运行覆盖测试的简单方法(最好通过 travis、goveralls 和 coveralls.io),其中可以使用 OS.exit( )
,并注明该测试的覆盖率。如果可以使用,我非常希望使用上面的 re-exec 方法(如果可以使用)。
解决方案应该显示 Crasher()
的覆盖率测试。从覆盖测试中排除 Crasher()
不是一种选择,因为在现实世界中,我正在尝试做的是测试一个更复杂的函数,在某些条件下,它会在内部深处调用例如log.Fatalf()
;我所进行的覆盖测试是针对这些条件的测试工作正常。
最佳答案
通过轻微的重构,您可以轻松实现 100% 的覆盖率。
foo/bar.go
:
package foo
import (
"fmt"
"os"
)
var osExit = os.Exit
func Crasher() {
fmt.Println("Going down in flames!")
osExit(1)
}
以及测试代码:foo/bar_test.go
:
package foo
import "testing"
func TestCrasher(t *testing.T) {
// Save current function and restore at the end:
oldOsExit := osExit
defer func() { osExit = oldOsExit }()
var got int
myExit := func(code int) {
got = code
}
osExit = myExit
Crasher()
if exp := 1; got != exp {
t.Errorf("Expected exit code: %d, got: %d", exp, got)
}
}
运行 go test -cover
:
Going down in flames!
PASS
coverage: 100.0% of statements
ok foo 0.002s
是的,如果 os.Exit()
,你可能会说这有效。被显式调用,但是如果 os.Exit()
被其他人调用怎么办,例如log.Fatalf()
?
同样的技术也适用,你只需要切换 log.Fatalf()
而不是 os.Exit()
,例如:
foo/bar.go
的相关部分:
var logFatalf = log.Fatalf
func Crasher() {
fmt.Println("Going down in flames!")
logFatalf("Exiting with code: %d", 1)
}
以及测试代码:foo/bar_test.go
中的TestCrasher()
:
func TestCrasher(t *testing.T) {
// Save current function and restore at the end:
oldLogFatalf := logFatalf
defer func() { logFatalf = oldLogFatalf }()
var gotFormat string
var gotV []interface{}
myFatalf := func(format string, v ...interface{}) {
gotFormat, gotV = format, v
}
logFatalf = myFatalf
Crasher()
expFormat, expV := "Exiting with code: %d", []interface{}{1}
if gotFormat != expFormat || !reflect.DeepEqual(gotV, expV) {
t.Error("Something went wrong")
}
}
运行 go test -cover
:
Going down in flames!
PASS
coverage: 100.0% of statements
ok foo 0.002s
关于unit-testing - 在 Go 中使用覆盖信息测试 os.Exit 场景 (coveralls.io/Goveralls),我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/40615641/