Implementation of service-testing helpers. #2452
Conversation
End-to-end testing of services with interceptors should be performed with a full gRPC stack, registered on a Server. This is a convenience package to abstract the boilerplate code associated with this setup. Includes a convenience wrapper around creating a grpc.Server communicating over a bufconn.Listener rather than a loopback TCP connection. The Tester can either be used directly if multiple services need to be registered, or via the NewClientConn() function which handles all setup and teardown.
End-to-end testing of services with interceptors should be performed with a full gRPC stack, registered on a Server. This is a convenience package to abstract the boilerplate code associated with this setup. Includes a convenience wrapper around creating a grpc.Server communicating over a bufconn.Listener rather than a loopback TCP connection. The Tester can either be used directly if multiple services need to be registered, or via the NewClientConn() function which handles all setup and teardown.
…ring to Server instead of Tester.
|
Thank you for your pull request. Before we can look at your contribution, we need to ensure all contributors are covered by a Contributor License Agreement. After the following items are addressed, please respond with a new comment here, and the automated system will re-verify.
Regards, |
…ring to Server instead of Tester.
…e implementation type to echo
|
@aschlosberg thank you for the contribution. Unfortunately, this is not something we would like to accept at this time. As discussed previously in a similar PR (#2186), I don't believe the native grpc API for creating and connecting to a server is sufficiently complicated to require a wrapper library. Wrapper libraries introduce the burden of learning another API, so it must be justified by hiding significant complexity in what it wraps. In addition, the process for testing a grpc service should be even simpler once we have implemented the in-process transport (after grpc/proposal#103 is done). If you are interesting in contributing to grpc-go, we do have a number of open issues tagged "Help Wanted". Please feel free to peruse the list and drop a comment in anything that sounds interesting and we can help make sure the issue is still relevant and provide any guidance needed to get you up to speed on it. Thanks! |
End-to-end testing of services should be performed with a full gRPC stack, registered on a Server and connected to via ClientConn. This is a convenience package to abstract the boilerplate code associated with this setup.
Includes a Tester wrapper around creating a grpc.Server communicating over a bufconn.Listener rather than a loopback TCP connection. The Tester can either be used directly if multiple services need to be registered, or via the NewClientConn() function which handles all setup and teardown.
As the ServiceDesc variables of generated proto files are not exported, this package accepts the RegisterXServer function along with its respective implementation, and calls the former with reflection.