Add utility for testing components that use GraphQlClient

[xenoterracide]

We're actively building a lot of code to integrate existing microservices into other services that are moving to a graphql interface. For now our services will remain REST. our services are "client only". What I'm looking for is an option akin to spring core's RestClientTest, where I can very quickly stub our limited responses with static responses. No idea for API at this time.

[rstoyanchev]

I'm not sure what RestClientTester is, but it sounds like MockRestServiceServer or based on it. There isn't anything exactly like that. However, you can use the same (i.e. MockRestServiceServer via RestClient/RestTemplate) to return canned GraphQL responses. It's just HTTP and doesn't necessarily need special handling, especially with canned responses.

You could also consider ExecutionGraphQlServiceTester, essentially GraphQlTester without a transport, and calling the GraphQL layer directly. You could add a little extra support around it to make it more convenient, like the MockExecutionGraphQlService that we use for own testing, for example here.

[xenoterracide]

google in it's infinite wisdom is having problems locating the reference/example documentation to

https://docs.spring.io/spring-boot/api/java/org/springframework/boot/test/autoconfigure/web/client/RestClientTest.html

baeldung has some though

https://www.baeldung.com/restclienttest-in-spring-boot

[bclozel]

I guess we're mixing things a bit here: what we'd like to test and how we'd like to test it, what Spring GraphQL can do to help and if/how Spring Boot can provide a test slice for this case.

I think that reproducing @RestClientTest with a MockRestServiceServer HTTP setup is not buying us much and can be done already today. Maybe considering a MockExecutionGraphQlService that plugs into a testing GraphQlTransport would work. The main problem is that we have specialized interfaces like HttpSyncGraphQlClient and that we promote specific static factory methods to create those using RestClient or WebClient. Components under test would probably need to have dedicated constructors accepting GraphQlTransport as well, but I think that if we provide a high-level testing utility this should still be a better solution.

[rstoyanchev]

On further thought, I don't think canned responses are feasible for GraphQL. There is no easy way to set up expected requests and responses given the ability to change the field selection set. For every query, there are many possibilities for what data exactly is requested and that determines what is returned.

When you have not implemented your GraphQL backend yet, using a GraphQL data mocking tool might be a better fit. As you begin to create your GraphQL application, keeping a facade between controllers and underlying services/repositories would help you to mock those out with mock services. So your tests would involve the GraphQL engine, but not a transport / HTTP server, and would return mock data.

[xenoterracide]

I think you would largely return a big pojo... Or multiple smaller ones... Whether or not that's mocking tools.

Also on my own reflection, I don't think whatever is created from this would actually be useful to us in my current scenario.

Reason being our clients aren't built on springs client. Apparently we encountered a performance issue when using clients provided by spring. The conjecture that I've heard is that because a new client is created every single time you make a request that the creation of the client was enough to cause a performance slowdown compared to what we had created. I am not the person that did this test. I might be able to get more details on that for another bug? Is there interest? Yes I know this is a tangent within this bug.

I don't even know if I have a use case for my hobby stuff right now. My use case is for front end technology which means the client is largely "JavaScript".