鉴于此代码
func doomed() {
os.Exit(1)
}
如何正确测试调用此函数是否会导致使用go test 退出？这需要在一组测试中进行，换句话说，os.Exit() 调用不会影响其他测试，应该被捕获。
【问题讨论】：
Exit“在世界的尽头”（main），like this pattern，那么你就不会像这里的（好）公认的解决方案那样编写痛苦的测试。我完全承认您可能一直在测试别人的代码，而您无法轻易重构，但只是希望这些建议对未来的读者有所帮助……
gexec package 非常适合以黑盒方式测试可执行文件的结果。
你不能，你必须使用exec.Command 并测试返回值。
【讨论】：
如果不从外部（使用exec.Command）过程模拟测试，我认为您无法测试实际的os.Exit。
也就是说，您可以通过创建接口或函数类型然后在测试中使用 noop 实现来实现您的目标：
package main
import "os"
import "fmt"
type exiter func (code int)
func main() {
doExit(func(code int){})
fmt.Println("got here")
doExit(func(code int){ os.Exit(code)})
}
func doExit(exit exiter) {
exit(1)
}
【讨论】：
测试代码：
package main
import "os"
var my_private_exit_function func(code int) = os.Exit
func main() {
MyAbstractFunctionAndExit(1)
}
func MyAbstractFunctionAndExit(exit int) {
my_private_exit_function(exit)
}
测试代码：
package main
import (
"os"
"testing"
)
func TestMyAbstractFunctionAndExit(t *testing.T) {
var ok bool = false // The default value can be omitted :)
// Prepare testing
my_private_exit_function = func(c int) {
ok = true
}
// Run function
MyAbstractFunctionAndExit(1)
// Check
if ok == false {
t.Errorf("Error in AbstractFunction()")
}
// Restore if need
my_private_exit_function = os.Exit
}
【讨论】：
os.Exit 放在一个变量中，并在生产代码中通过这个变量调用它，而在测试中你可以用另一个函数替换它的值'不退出，但如果它被调用，会通知你。如果您有能力修改生产代码以提高其可测试性，这是一个有效的解决方案。
Andrew Gerrand（Go 团队的核心成员之一）在 presentation 中展示了如何做到这一点。
给定一个函数（main.go）
package main
import (
"fmt"
"os"
)
func Crasher() {
fmt.Println("Going down in flames!")
os.Exit(1)
}
这是您将如何测试它（通过main_test.go）：
package main
import (
"os"
"os/exec"
"testing"
)
func TestCrasher(t *testing.T) {
if os.Getenv("BE_CRASHER") == "1" {
Crasher()
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() {
return
}
t.Fatalf("process ran with err %v, want exit status 1", err)
}
代码所做的是通过exec.Command 在单独的进程中再次调用go test，将执行限制为TestCrasher 测试（通过-test.run=TestCrasher 开关）。它还通过第二次调用检查的环境变量 (BE_CRASHER=1) 传入一个标志，如果设置，则调用被测系统，然后立即返回以防止陷入无限循环。因此，我们被退回到原来的调用站点，现在可以验证实际的退出代码。
来源：Slide 23 Andrew 的演示文稿。第二张幻灯片也包含指向presentation's video 的链接。 他在47:09
谈论子流程测试【讨论】：
process ran with err exec: "cmd": executable file not found in $PATH, want exit status 1
main.go 和 main_test.go？我修改了答案并仔细检查了它是否可以在我的机器上运行。
go env 有问题？我总是使用go test 进行测试，并且我还创建了几个测试来测试其他文件。
我使用bouk/monkey：
func TestDoomed(t *testing.T) {
fakeExit := func(int) {
panic("os.Exit called")
}
patch := monkey.Patch(os.Exit, fakeExit)
defer patch.Unpatch()
assert.PanicsWithValue(t, "os.Exit called", doomed, "os.Exit was not called")
}
monkey 在处理此类工作、故障注入和其他困难任务时非常强大。它确实来了with some caveats。
【讨论】：