因为gRPC Python客户端默认依赖运行中的服务端，而单元测试需隔离，直接连真实服务会将单元测试降级为慢、不稳定、难调试的集成测试。
为什么不能直接用pytest调用gRPC服务的Python客户端？
因为gRPC Python客户端默认依赖运行中的服务端，而单元测试需要隔离——你得让测试不依赖真实网络或外部进程。直接在测试里启动grpcio-server并连它，会把单元测试拖成集成测试，慢、不稳定、难调试。
真正高效的做法是：用grpc.aio.insecure_channel配合grpc_testing或unittest.mock打桩，或者更推荐——启动一个轻量、可复位的in-process测试服务实例（非子进程，无端口冲突）。
- 别用
subprocess.Popen起真实server：端口占用、清理麻烦、失败后残留 - 避免在
setup_method里每次重连channel：复用channel对象能省掉重复握手开销 -
grpcio-testing已弃用且不支持async，新项目绕开它
如何用pytest.fixture安全启动和清理in-process gRPC server？
核心是用grpc.server搭配concurrent.futures.ThreadPoolExecutor，不绑定真实地址，而是用grpc.insecure_channel('localhost:0')配合server.add_insecure_port('[::]:0')动态分配端口，再通过server.add_generic_rpc_handlers或注册具体servicer。
关键点在于：server必须在fixture中启动，但不能阻塞pytest主线程；要用threading.Event等机制确认server ready，且teardown时必须server.stop(0).wait()，否则pytest退出时线程可能被强杀导致资源泄漏。
立即学习“Python免费学习笔记（深入）”；
- fixture scope设为
function，避免测试间状态污染 - 不要用
localhost:50051这种固定端口：多测试并行时会冲突 - 在server启动后主动调用一次
channel.channel_ready()确保连接就绪，否则首请求可能报StatusCode.UNAVAILABLE - 示例片段：
import grpc<br>from concurrent.futures import ThreadPoolExecutor<br><br>@pytest.fixture<br>def grpc_server():<br> server = grpc.server(ThreadPoolExecutor(max_workers=1))<br> # 注册你的servicer...<br> server.add_insecure_port('[::]:0')<br> port = server.add_insecure_port('[::]:0') # 实际分配的端口<br> server.start()<br> yield f'localhost:{port}'<br> server.stop(0).wait()
测试异步gRPC stub时，pytest-asyncio和grpc.aio怎么配才不报错？
错误常见于混用同步/异步stack：比如用grpc.insecure_channel（同步）配grpc.aio.Stub（异步），会直接抛AttributeError: 'Channel' object has no attribute 'unary_unary'。必须全程用aio栈。
- channel必须是
grpc.aio.insecure_channel(...)，不是grpc.insecure_channel - stub必须由
your_pb2_grpc.YourServiceStub(channel)构造，且channel是aio类型 - 测试函数要加
@pytest.mark.asyncio，且用await调用stub方法，例如await stub.SayHello(req) - 如果stub方法返回
grpc.aio.UnaryUnaryCall，记得await两次：一次触发调用，一次取结果（await (await stub.SayHello(req)).code()）
如何验证gRPC请求是否真的走到了servicer逻辑，而不是mock或空响应？
最可靠的方式不是检查返回值，而是给servicer加可观察的钩子：比如用threading.local()存请求上下文，或在servicer方法开头插入print/logging.debug（配合caplog fixture捕获），或更进一步——用unittest.mock.Mock包装servicer的业务方法，断言是否被调用及参数是否匹配。
- 别只测
response.code == StatusCode.OK：这只能说明gRPC层通了，不代表业务逻辑执行了 - 在servicer里加一个
self._call_count = getattr(self, '_call_count', 0) + 1，测试后检查该属性值 - 对复杂请求体，用
google.protobuf.json_format.MessageToJson比对原始request字段，避免因protobuf序列化细节导致误判 - 注意
grpcio版本兼容性：1.60+对aio的异常传播更严格，旧版吞掉的Exception在新版会变成grpc.aio.AioRpcError
真实项目里最难缠的往往是server生命周期管理与async stub的等待时机——这两处出问题，测试会随机失败，而不是稳定报错。
