Presently the SuiteConfigs require a server interface:
|
server := examplefreightv1.UnimplementedFreightServiceServer{} |
|
// setup test suite |
|
suite := examplefreightv1.FreightServiceTestSuite{ |
|
T: t, |
|
Server: server, |
|
} |
Testing the server handlers directly may miss on behavior that happens between clients and servers (auth interceptors that populate ctxs, validators like buf-validate, etc), so we'd rather give the SuiteConfig the client interface rather than the server interface. That would let us control the grpc server that is tested against.
A workaround is masquerading the clients as a server, but its pretty tedious:
type ServerThatsActuallyClients struct {
clients mypb.MyClient
}
func (c ServerThatsActuallyClients) CreateSite(ctx context.Context, req *mypb.CreateSiteRequest) (*mypb.Site, error) {
return c.clients.CreateSite(ctx, req)
}
func (c ServerThatsActuallyClients) CreateShipper(ctx context.Context, req *mypb.CreateShipperRequest) (*mypb.Shipper, error) {
return c.clients.CreateShipper(ctx, req)
}Do we have any thoughts about this?
Presently the SuiteConfigs require a server interface:
protoc-gen-go-aip-test/example/freight_service_test.go
Lines 16 to 21 in 02f5496
Testing the server handlers directly may miss on behavior that happens between clients and servers (auth interceptors that populate ctxs, validators like buf-validate, etc), so we'd rather give the
SuiteConfigthe client interface rather than the server interface. That would let us control the grpc server that is tested against.A workaround is masquerading the clients as a server, but its pretty tedious:
Do we have any thoughts about this?