feature: `protoc-gen-go-grpc` to create test client / `bufconn` constructors about grpc-go HOT 2 CLOSED

Thanks for the suggestion.

I think you can do this with a more general function instead. The function would accept a *grpc.Server that has been created by the test with the right pb.Regster* functions already called on it. It would create the bufconn listener and return a ClientConn connected to it. Then the test would do client := pb.FooClient(cc).

I.e.

package bufconntesting

func StartBufConnService(s *grpc.Server) (*grpc.ClientConn, error) {
	// (mostly just your code above:)
	t.Helper()

	lis := bufconn.Listen(1 << 10)
	go func() {
		if err := srv.Serve(lis); err != nil {
			t.Logf("service exited with error: %v", err)
		}
	}()

	t.Cleanup(func() {
		srv.GracefulStop()
		lis.Close()
	})

	return grpc.NewClient(
		"bufnet",
		grpc.WithTransportCredentials(insecure.NewCredentials()),
		grpc.WithContextDialer(func(ctx context.Context, _ string) (net.Conn, error) {
			return lis.DialContext(ctx)
		}),
	)
	require.NoError(t, err)
}

---

package some_test

func TestFoo(t *testing.T) {
	s := grpc.NewServer(<whatever opts this test case likes>)
	mypb.RegisterFooService(s)
	cc, err := StartBufConnService(s)
	if err != nil { t.Fatal() }
	client := pb.FooClient(cc)
	// use client
}

One problem you'll run into is that if a test case wants custom dial options, now you'll need to pass those in, too. (I avoided that problem by making the test create the server.) This is why I'm generally not a fan of testing helpers like this, although we do use them to some extent in our own tests. This and other opinions that you have in the code (e.g. to simply log the error if Serve exits with one, vs. calling t.Error) are reasons why we can't really be in the business of standardizing this kind of thing.

from grpc-go.

Yeah, fair enough!

from grpc-go.