TCP 侦听器服务在Go测试中由于超时而失败

今天golang学习网给大家带来了《TCP 侦听器服务在Go测试中由于超时而失败》，其中涉及到的知识点包括等等，无论你是小白还是老手，都适合看一看哦~有好的建议也欢迎大家在评论留言，若是看完有所收获，也希望大家能多多点赞支持呀！一起加油学习~

我有这个单元测试：

func testserver(t *testing.t) {
    db := preparedbconn(t)
    defer db.close()
    lis := bufconn.listen(1024 * 1024)
    t.logf("opened listener: %v", lis)

    grpcserver := grpc.newserver(
        withunaryinterceptor(),
    )
    t.logf("opened grpc server: %v", grpcserver)
    signkey := getsignkey()
    if signkey == nil {
        t.fatal("failed to find or parse rsa private key")
    }

    verifykeyerr := setverifykey()
    if verifykeyerr != nil {
        t.fatal("failed to find or parse rsa public key")
    }

    pb.registerauthserviceserver(grpcserver, newauthserviceserver(db, signkey))

    err := grpcserver.serve(lis)
    if err != nil {
        t.fatalf("failed to listen: %+v", err)
    }
}

如果我注释掉最后 4 行：

// err := grpcserver.serve(lis)
    // if err != nil {
    //   t.fatalf("failed to listen: %+v", err)
    // }

它每次都会通过，但无论出于何种原因，它都会在 err := grpcserver.server(lis) 行处变得糟糕。我尝试过使用真正的 tcp 侦听器（将 lis := bufconn.listen 与 lis := net.listen("tcp") 交换。测试的输出（当失败时）很长且不明确：

panic: test timed out after 2m0s

goroutine 34 [running]:
testing.(*m).startalarm.func1()
        /usr/local/cellar/go/1.12.7/libexec/src/testing/testing.go:1334 +0xdf
created by time.gofunc
        /usr/local/cellar/go/1.12.7/libexec/src/time/sleep.go:169 +0x44

goroutine 1 [chan receive]:
testing.(*t).run(0xc000156100, 0x15cb741, 0xa, 0x15ed1a8, 0x10b38a6)
        /usr/local/cellar/go/1.12.7/libexec/src/testing/testing.go:917 +0x381
testing.runtests.func1(0xc000156000)
        /usr/local/cellar/go/1.12.7/libexec/src/testing/testing.go:1157 +0x78
testing.trunner(0xc000156000, 0xc0000c1e10)
        /usr/local/cellar/go/1.12.7/libexec/src/testing/testing.go:865 +0xc0
testing.runtests(0xc00000e0c0, 0x1a53d60, 0x3, 0x3, 0x0)
        /usr/local/cellar/go/1.12.7/libexec/src/testing/testing.go:1155 +0x2a9
testing.(*m).run(0xc00013e000, 0x0)
        /usr/local/cellar/go/1.12.7/libexec/src/testing/testing.go:1072 +0x162
_/path/to/my/server.testmain(0xc00013e000)
        /path/to/my/server/main_test.go:102 +0x2b
main.main()
        _testmain.go:44 +0x13e

goroutine 19 [chan receive]:
github.com/golang/glog.(*loggingt).flushdaemon(0x1a5f540)
        /my/gopath/src/github.com/golang/glog/glog.go:882 +0x8b
created by github.com/golang/glog.init.0
        /my/gopath/src/github.com/golang/glog/glog.go:410 +0x272

goroutine 5 [select]:
google.golang.org/grpc/test/bufconn.(*listener).accept(0xc00000e0e0, 0x15edf50, 0xc000176000, 0xc00000e420, 0x0)
        /my/gopath/src/google.golang.org/grpc/test/bufconn/bufconn.go:51 +0xaf
google.golang.org/grpc.(*server).serve(0xc000176000, 0x1684880, 0xc00000e0e0, 0x0, 0x0)
        /my/gopath/src/google.golang.org/grpc/server.go:586 +0x1f2
_/path/to/my/server.testserver(0xc000156100)
        /path/to/my/server/main_test.go:67 +0x309
testing.trunner(0xc000156100, 0x15ed1a8)
        /usr/local/cellar/go/1.12.7/libexec/src/testing/testing.go:865 +0xc0
created by testing.(*t).run
        /usr/local/cellar/go/1.12.7/libexec/src/testing/testing.go:916 +0x35a

goroutine 6 [select]:
database/sql.(*db).connectionopener(0xc00013a0c0, 0x1685780, 0xc00006a300)
        /usr/local/cellar/go/1.12.7/libexec/src/database/sql/sql.go:1000 +0xe8
created by database/sql.opendb
        /usr/local/cellar/go/1.12.7/libexec/src/database/sql/sql.go:670 +0x15e

goroutine 7 [select]:
database/sql.(*db).connectionresetter(0xc00013a0c0, 0x1685780, 0xc00006a300)
        /usr/local/cellar/go/1.12.7/libexec/src/database/sql/sql.go:1013 +0xfb
created by database/sql.opendb
        /usr/local/cellar/go/1.12.7/libexec/src/database/sql/sql.go:671 +0x194
exit status 2

它没有告诉我出了什么问题（除了超时）并且似乎还参考了其他库的测试？我通过 vs-code 调用测试，它使用以下命令：

/usr/local/bin/go test -timeout 30s -run ^(TestServer)$

我可以构建并运行该包，它完全按照我的预期工作，并且不会在那一行失败，所以我认为我在单元测试方面做了一些错误的事情，但在这一点上我没有太多可做的而且我对 go 测试不太了解。

解决方案

服务是一个阻塞调用。它将等待新的连接并在它们进来时无限期地处理它们。这就是它的全部目的 - 在服务器关闭或崩溃之前它不会返回。 Per the documentation for Serve：

Serve 接受监听器上的传入连接，为每个连接创建一个新的 ServerTransport 和服务 goroutine。服务 goroutine 读取 gRPC 请求，然后调用注册的处理程序来回复它们。当 lis.Accept 因致命错误而失败时，Serve 返回。

对于您的其他问题：

它没有告诉我出了什么问题（除了超时）

这就是问题所在。 go test有时间限制，测试超过了。其实没有什么可说的了。它提供了堆栈跟踪，这有助于确定超时的原因，因为它们会告诉您每个 goroutine 超时时的位置（例如 goroutine 5 正在 Listener.Accept 中等待新连接） .

似乎也参考了其他库的测试

不是测试（这些测试位于 _test.go 文件中），只是代码引用的库中的代码。它们是堆栈跟踪，通常包含来自标准库和/或第三方库的代码，因为它是跟踪时该 goroutine 的调用堆栈的一部分。

据我所知看，您正在尝试对 gRPC 服务器进行单元测试。您尝试使用的策略对于单元测试来说有点过分了。

为了简单起见，您应该有一个服务器结构来保存互连的部分，例如：数据库连接。

因此，您只需初始化数据库连接并将其传递给服务器结构。这是模拟数据库的正确位置。 之后，您将拥有启动 gRPC 服务器实例，因为您不需要拨打 gRPC 进行单元测试。

然后你就可以在初始化的Server实例上调用预期的rpc函数了。它看起来更加干净和可维护。

今天带大家了解了的相关知识，希望对你有所帮助；关于Golang的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~