unit-testing - 尝试在 TCP 监听器上提供服务时，由于超时，Go 测试模棱两可地失败

Question

我有这个单元测试:

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)$

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

Answer 1

如我所见，您正在尝试对 gRPC 服务器进行单元测试。您尝试使用的策略对于单元测试来说有点矫枉过正。

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

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

然后您可以在初始化的服务器实例上调用预期的 rpc 函数。它看起来更清洁和可维护。