使用Golang进行gRPC服务的端到端测试_模拟Client与Server

真正隔离的端到端grpc测试应使用bufconn内存管道，client需配withcontextdialer+bufconn.dialer，server注册必须用指针接收者并调用srv.serve(lis)，handler须监听ctx.done()验证取消。

怎么在 go 里不启真实 server 就测 gRPC 接口

直接用 grpc.Dial 连本地端口，本质还是依赖运行中的服务，没法做纯单元测试。真正隔离的端到端测试，得用 bufconn —— 它提供内存管道（in-memory listener），Client 和 Server 都走这个管道，零网络、无端口冲突、启动快。

常见错误是把 bufconn.Listen 返回的 *bufconn.Listener 直接传给 grpc.NewServer()，这没问题；但 Client 端用 grpc.Dial 时，必须配 grpc.WithContextDialer + bufconn.Dialer，否则 Dial 会卡住或报 connection refused。

• bufconn 不是标准库，需 go get google.golang.org/grpc/x/net/bufconn
• Listener 的 buffer size（如 bufconn.Listen(1024 * 1024)）要大于单次请求/响应体，否则可能阻塞或丢数据
• Server 必须调用 lis.Close() 或用 defer lis.Close()，否则 test goroutine 可能 leak

如何让 mock client 发出带 metadata 和 timeout 的真实调用

gRPC 的 context.WithTimeout 和 metadata.MD 是透传到 server 端的，但很多人只在 client 端设了 context，却没在 server handler 里显式读取 metadata.FromIncomingContext 或检查 ctx.Err() == context.DeadlineExceeded，导致“超时没生效”或“header 拿不到”。

实操上，client 调用前构造 context 即可，不用改 stub：

立即学习“go语言免费学习笔记（深入）”；

ctx, cancel := context.WithTimeout(context.Background(), 500*time.Millisecond) defer cancel() md := metadata.Pairs("auth-Token", "test-123") ctx = metadata.InjectOutgoingContext(ctx, md) <p>resp, err := client.SayHello(ctx, &pb.HelloRequest{Name: "Alice"})

• metadata key 自动转小写，"Auth-Token" 会被变成 "auth-token"
• timeout 是对整个 RPC 调用生效，不是单个 send/recv；如果 handler 里有阻塞操作（如 sleep），必须主动 select ctx.Done()
• server 端用 metadata.FromIncomingContext(ctx) 拿 metadata，不是 FromOutgoingContext

为什么 TestServer 注册 service 后调用返回 UNIMPLEMENTED

典型现象：server 启起来了，client dial 成功，但一调就报 rpc Error: code = Unimplemented desc = method XXX not implemented。根本原因不是函数没写，而是注册顺序或对象不对 —— pb.RegisterXXXServer 第二个参数必须是实现了对应 Interface 的 Struct 实例，且该 struct 方法必须是 **指针接收者**。

比如你定义了：

type HelloService struct{} func (h HelloService) SayHello(...) {...} // ❌ 值接收者 → 不满足 pb.HelloServiceServer 接口

正确写法是：

func (h *HelloService) SayHello(...) {...} // ✅ 指针接收者 ... srv := grpc.NewServer() pb.RegisterHelloServiceServer(srv, &HelloService{}) // 注意这里传指针

• Go 接口实现是隐式的，编译器不会报错，但 runtime 会拒绝注册值接收者的方法
• 如果用 embed 方式组合多个 service，确保每个嵌入字段都是指针类型，且外层 struct 方法也用指针接收
• 注册后别漏掉 srv.Serve(lis)，否则 listener 不会处理连接（哪怕 bufconn 也是）

如何验证 server 端是否真的收到了 client 的 cancellation

单纯看 client 报 context canceled 不够，得确认 server handler 是否及时退出、有没有资源泄漏。最可靠的方式是在 handler 里加 select 监听 ctx.Done()，并在 case 中打日志或设标志位。

例如：

func (s *HelloService) SayHello(ctx context.Context, req *pb.HelloRequest) (*pb.HelloResponse, error) {     done := make(chan struct{})     go func() {         <-ctx.Done()         log.Println("server received cancellation:", ctx.Err())         close(done)     }()     // 模拟耗时操作     select {     case <-time.After(2 * time.Second):         return &pb.HelloResponse{Message: "hello"}, nil     case <-done:         return nil, status.Error(codes.Canceled, "canceled by client")     } }

• 不要在 handler 里直接 time.Sleep，它不响应 cancel；必须用 select + ctx.Done()
• server 返回 codes.Canceled 后，client 的 err 会是 context.Canceled，但前提是 server 显式返回，不是 panic 或 panic recover
• 如果 handler 启了 goroutine 且没传 ctx，cancel 不会自动传播，得手动监听并 stop

测试里最容易被忽略的，是 bufconn listener 的生命周期和 server.Serve 的 goroutine 管理 —— 它既不能提前 close，也不能忘记 stop，否则 test 会 hang 或 panic。