Tracking Issue for Testing utilities being Experimental.

[carl-mastrangelo]

Specific usages;

• StreamRecorder
• TestUtils

[dapengzhang0]

not stabilized yet, keep unscheduled.

[trustin]

I realized that all members of TestUtils have been deprecated. We use them for our gRPC interop tests:

https://github.com/line/armeria/blob/master/it/src/test/java/com/linecorp/armeria/server/grpc/interop/ArmeriaGrpcServerInteropTest.java#L80

I also see a similar problem on the client side. We need TestUtils.newSslSocketFactoryForCa().

What would be the recommended way to run this sort of interop tests?

[dapengzhang0]

@trustin I think you can define/fork your own function similar to TestUtils.newSslSocketFactoryForCa(), it's not hard because the function is not dependent on gRPC library.

The source code is at
https://github.com/grpc/grpc-java/blob/master/testing/src/main/java/io/grpc/internal/testing/TestUtils.java

[ejona86]

If certain methods are useful, have a reasonable API, and are maintainable, we can keep them.

@trustin, details about your test:

• It is not using GrpcSslContexts. It can override trustManager after configuring the SslContext via GrpcSslContexts, but it should pass through GrpcSslContexts.
• preferredTestCiphers() really should have been internal. Although you are using it the same as we are (testing OkHttp on the JDK). This was needed when the JDK's GCM went at 2 MB/s. Now it's 10x that and JDK 9 will be 10x again. So maybe we just drop it. Alternatively we can kill it in favor of Conscrypt. It is only helpful with Jetty ALPN. Conscrypt is very close to 1.0 with pre-built binaries for multiple platforms. But OkHttp will need some fixes to make use of it off-Android.
• The usage of newSslSocketFactoryForCa is coupled with a usage of io.grpc.okhttp.internal.Platform. That's obviously not supported. But I understand the need.
• There's a usage of GrpcUtil.authorityFromHostAndPort which is also internal. It could have been just "example.com:" + port. A big reason for the utility is to handle IPv6 IPs which need []. That's unnecessary in the test

I'm fine to work out utility functions for using test certificates. I understand that is a major PITA and using grpc's pre-generated test certs makes things much easier. But I expect they could be simplified.

For example, Netty now has InputStream-based methods for some of these things. loadCert() could actually just return an InputStream. That means loadX509Cert is probably unnecessary now-a-days.

Functionality that looks good to keep (but maybe renamed/moved/tweaked):

• One-line impl for InputStream loadCert(String name)
• newSslSocketFactoryForCa() it is useful for OkHttp, but... providing Provider is a problem. Maybe we can add a method to OkHttpChannelBuilder. Maybe trustManagerFactory(TrustManagerFactory) (+ testing utility) or trustCertificates(InputStream) that is used when we create our SSLContext. That would avoid needing to specify a Provider.

[trustin]

@ejona86 Thanks a lot for the detailed suggestions and ideas. Using GrpcSslContexts simplified things quite a bit. Let me keep the usage of loadCert() and newSslSocketFactoryForCa() for the time being.

[dapengzhang0]

Deprecated io.grpc.testing.StreamRecorder in v1.8.0 and to be removed at v1.9.0

[dapengzhang0]

Deprecated public static ServerInterceptor recordServerCallInterceptor( final AtomicReference<ServerCall<?, ?>> serverCallCapture) in v1.8.0 and to be removed at v1.9.0

[JanecekPetr]

I see that StreamRecorder has been deprecated with a comment:

Most users should use blocking stubs instead.

Wait, how? How do we use a blocking stub in bidirectional streaming calls? That's exactly what we've been using StreamRecorder for. It's a shame that a useful testing utility is going away without any replacement / alternative.

To use properly, you must know the class's implementation; if you liked it, copy the code to your own codebase

We absolutely will copy the class. I don't understand the "you must know the class's implementation" part, though. The class is nicely JavaDoc'ed and we've been using it for quite some time without any knowledge about its implementation. What are the details that we need to know and how can we misuse the class? It seems to be dead simple.