我有這個單元測試：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 測試了解不多。
2 回答
哆啦的時光機
TA貢獻1779條經驗 獲得超6個贊
正如我所看到的，您正在嘗試對 gRPC 服務器進行單元測試。您嘗試使用的策略對于單元測試來說是相當過大的。
為簡單起見，您應該有一個服務器結構來保存互連的部分，例如：數據庫連接。
因此，您只需初始化數據庫連接并將其傳遞給服務器結構。這是模擬數據庫的正確位置。之后，您將擁有啟動 gRPC 服務器實例，因為您不需要撥打 gRPC 進行單元測試。
然后，您可以在初始化的 Server 實例上調用預期的 rpc 函數。它看起來更加干凈和可維護。
富國滬深
TA貢獻1790條經驗 獲得超9個贊
服務是一個阻塞調用。它將等待新的連接并在它們進來時無限期地處理它們。這就是它的全部目的 - 在服務器關閉或崩潰之前它不會返回。根據文檔Serve：
Serve 接受監聽器上的傳入連接，為每個連接創建一個新的 ServerTransport 和服務 goroutine。服務 goroutine 讀取 gRPC 請求，然后調用注冊的處理程序來回復它們。當 lis.Accept 因致命錯誤而失敗時，Serve 返回。
對于您的其他問題：
它沒有告訴我出了什么問題（除了超時）
這就是問題所在。go test有時間限制，而測試超過了時間。其實沒有什么可說的了。它提供了堆棧跟蹤，這有助于確定超時的原因，因為它們告訴您每個 goroutine 超時時的位置（例如 goroutine 5 正在等待新連接Listener.Accept）。
似乎也參考了其他庫的測試
不是測試（那些將在_test.go文件中），只是代碼引用的庫中的代碼。它們是堆棧跟蹤，通常包含來自標準庫和/或第三方庫的代碼，因為它是跟蹤時該 goroutine 的調用堆棧的一部分。
- 2 回答
- 0 關注
- 139 瀏覽
添加回答
舉報
0/150
提交
取消