21

这个问题：如何在 Go 中测试 os.exit 场景（以及其中投票最高的答案）阐述了如何在 Go 中测试os.Exit()场景。由于os.Exit()不容易被拦截，使用的方法是重新调用二进制文件并检查退出值。此方法在Andrew Gerrand（Go 团队的核心成员之一）的演示文稿的幻灯片 23 中进行了描述；该代码非常简单，并在下面完整复制。

相关的测试和主文件看起来像这样（注意这对文件单独是一个 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)
}

但是，这种方法似乎受到某些限制：

  1. 使用 goveralls/coveralls.io 进行覆盖测试不起作用 - 例如，请参见此处的示例（与上面的代码相同，但为方便起见放入 github），它在此处生成覆盖测试，即它不记录正在运行的测试函数。请注意，您不需要这些链接来回答问题 - 上面的示例可以正常工作 - 它们只是为了展示如果您将上述内容放入 github 并通过 travis 一直到 coveralls.io 会发生什么

  2. 重新运行测试二进制文件似乎很脆弱。

具体来说，根据要求，这是覆盖失败的屏幕截图（而不是链接）；红色阴影表示就 coveralls.io 而言，Crasher()没有被调用。

覆盖测试显示没有调用 Crasher()

有没有解决的办法？特别是第一点。

在 golang 级别，问题是这样的：

  • Goveralls 框架运行go test -cover ...，它调用上面的测试。

  • 上面的测试在exec.Command / .Run没有-cover操作系统参数的情况下调用

  • 无条件地将-coveretc. 放入参数列表是没有吸引力的，因为它会在非覆盖测试中运行覆盖测试（作为子进程），并且解析参数列表是否存在-coveretc. 似乎是一个繁重的解决方案。

  • 即使我将-cover等放在参数列表中，我的理解是我会将两个覆盖输出写入同一个文件，这是行不通的 - 这些需要以某种方式合并。我最接近的是这个 golang issue。

概括

我所追求的是一种运行覆盖测试的简单方法（最好通过 travis、goveralls 和 coveralls.io），其中可以同时测试被测试例程以 退出的OS.exit()测试用例，以及记录该测试的覆盖率. 如果可以使其工作，我非常希望它使用上面的 re-exec 方法（如果可以工作的话）。

该解决方案应显示Crasher(). 排除Crasher()覆盖测试不是一种选择，因为在现实世界中，我想做的是测试一个更复杂的函数，在某些条件下，它会调用例如log.Fatalf()；我要进行的覆盖测试是针对这些条件的测试可以正常工作。

4

3 回答 3

23

通过轻微的重构，您可以轻松实现 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)
}

和测试代码：TestCrasher()在foo/bar_test.go：

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
于 2016-11-25T09:36:53.113 回答
7

接口和模拟

使用 Go 接口可以创建可模拟的组合。一个类型可以有接口作为绑定依赖。这些依赖关系可以很容易地用适合接口的模拟替换。

type Exiter interface {
    Exit(int)
}

type osExit struct {}

func (o* osExit) Exit (code int) {
    os.Exit(code)
}

type Crasher struct {
    Exiter
}

func (c *Crasher) Crash() {
    fmt.Println("Going down in flames!")
    c.Exit(1)
}

测试

type MockOsExit struct {
    ExitCode int
}

func (m *MockOsExit) Exit(code int){
    m.ExitCode = code
}

func TestCrasher(t *testing.T) {
    crasher := &Crasher{&MockOsExit{}}
    crasher.Crash() // This causes os.Exit(1) to be called
    f := crasher.Exiter.(*MockOsExit)
    if f.ExitCode == 1 {
        fmt.Printf("Error code is %d\n", f.ExitCode)
        return
    }
    t.Fatalf("Process ran with err code %d, want exit status 1", f.ExitCode)
}

缺点

原始Exit方法仍然不会被测试，所以它应该只负责退出，仅此而已。

函数是一等公民

参数依赖

函数是 Go 中的一等公民。函数允许很多操作，所以我们可以直接用函数做一些技巧。

使用“作为参数传递”操作，我们可以进行依赖注入：

type osExit func(code int)

func Crasher(os_exit osExit) {
    fmt.Println("Going down in flames!")
    os_exit(1)
}

测试：

var exit_code int 
func os_exit_mock(code int) {
     exit_code = code
}

func TestCrasher(t *testing.T) {

    Crasher(os_exit_mock) // This causes os.Exit(1) to be called
    if exit_code == 1 {
        fmt.Printf("Error code is %d\n", exit_code)
        return
    }
    t.Fatalf("Process ran with err code %v, want exit status 1", exit_code)
}

缺点

您必须将依赖项作为参数传递。如果您有许多依赖项，则参数列表的长度可能会很大。

变量替换

实际上，可以使用“分配给变量”操作来完成它，而无需显式传递函数作为参数。

var osExit = os.Exit

func Crasher() {
    fmt.Println("Going down in flames!")
    osExit(1)
}

测试

var exit_code int
func osExitMock(code int) {
    exit_code = code
}

func TestCrasher(t *testing.T) {
    origOsExit := osExit
    osExit = osExitMock
    // Don't forget to switch functions back!
    defer func() { osExit = origOsExit }()

    Crasher()
    if exit_code != 1 {
        t.Fatalf("Process ran with err code %v, want exit status 1", exit_code)
    }
}

缺点

它是隐含的，容易崩溃。

设计说明

如果您打算在退出后声明一些逻辑，Exit则退出逻辑必须在退出后用else块或额外隔离，return因为模拟不会停止执行。

func (c *Crasher) Crash() {
    if SomeCondition == true {
        fmt.Println("Going down in flames!")
        c.Exit(1)  // Exit in real situation, invoke mock when testing
    } else {
        DoSomeOtherStuff()
    }

}
于 2016-11-27T13:08:06.217 回答
-1

由于此类问题Main，专门针对应用程序的功能进行测试并不常见。GOLANG有一个已经回答的问题触及了同样的问题。

显示没有盲点的功能测试覆盖率

总结

总而言之，您应该避免在应用程序的主要入口点周围进行测试，并尝试以很少的代码在Main函数上的方式设计您的应用程序，以便它足够解耦以允许您测试尽可能多的代码。

查看GOLANG 测试以获取更多信息。

覆盖率达 100%

正如我在上一个答案中详述的那样，尝试围绕Mainfunc 进行测试是一个坏主意，最佳做法是在其中放置尽可能少的代码，以便可以在没有盲点的情况下正确测试它，这是有理由尝试的在尝试包含Mainfunc 时获得 100% 的覆盖率是浪费精力，因此最好在测试中忽略它。

您可以使用构建标签main.go从测试中排除文件，从而达到100%的覆盖率或全绿色。

检查：显示没有盲点的功能测试覆盖率

如果你很好地设计你的代码并保持所有实际功能很好地解耦和测试有几行代码做的很少，然后调用实际的代码片段来完成所有实际工作并经过很好的测试它并不重要你不是在测试一个微小而不重要的代码。

于 2016-11-24T11:31:51.590 回答