尝试在 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")）。它没有告诉我出了什么问题（除了超时）并且似乎还参考了其他库的测试？我通过调用测试vs-code，它使用以下命令：/usr/local/bin/go test -timeout 30s -run ^(TestServer)$我可以构建并运行该包，它完全按照我的预期工作，并且不会在那条线上失败，所以我认为我在单元测试方面做错了一些事情，但在这一点上我没有太多要做的，而且我不这样做对 go 测试了解不多。

Answer 1

正如我所看到的，您正在尝试对 gRPC 服务器进行单元测试。您尝试使用的策略对于单元测试来说是相当过大的。

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

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

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

Answer 2

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

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

对于您的其他问题：

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

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

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

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