-
Notifications
You must be signed in to change notification settings - Fork 311
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GraphQlTester should go by the schema when serializing variables #569
Comments
Not sure what you mean by normal flow because serialization happens on the client side and it could be any client, any language, and this is completely independent of anything GraphQL Java does on the server side which involves only deserialization for request input.
|
I don't understand this. GraphQL Java must somehow convert/serialize the return types of the queries/mutations to JSON and custom scalar converters must be taken into account, i.e. generic mappers like Jackson cannot be used. OTOH I understand that My motivation basically is that while the approach with |
No, GraphQL Java doesn't serialize anything to JSON. It goes field by field and assembles the output map. I'm not really sure what's going on from this level of detail. Something less than obvious perhaps. The only other suggestion I have is that maybe |
Is this method also used if the transport is (Perhaps there's just a misunderstanding of what serialization really means in this case. Creating the map out of the object is IMO also part of the serialization process...) |
No, that's apples and oranges. What I talked about is GraphQL Java on the server side returning an What you're asking about is |
Is it possible to provide a small sample that demonstrates a concrete issue? |
Re-reading the description again, I think I'm beginning to understand. I think your expectation is that GraphQL Java indeed does something similar, but that's on the server side and it's for responses, and it's slightly different because it's checking against the field selection set rather than directly against the schema types. In any case, it's not something that can be re-used on the client side. It's a valid potential enhancement, assuming I've got it right, for |
I've improved that documentation note in 089c754, based on this conversation. |
Exactly! I think, though, the problem has two parts:
Anyway, I'm glad that you consider this as an enhancement. This would greatly improve code reuse in tests because typically you have very similar fixtures for asserting server output as for providing server input (on the client side). |
I don't know of a more appropriate place so I will try to ask a related question here. Is it possible to use a different ObjectMapper for GraphQlTester client than for the server in a single SpringBootTest? I need the serialize test data differently than deserialize them on the server. |
It depends on the types of tests and |
Motivation
My output types in the schema are the same as my input types except the latter ones don't have
id
field. For conciseness reasons, I use the same underlying DTO with nullable id for both types. This works well in the main code flow becauseid
is set to null on input while it has some value on the output.In the tests, though, I want to use my DTOs as input variables, e.g.
Now I obviously don't want the variable
var
to contain theid
field because it's not defined in the input type corresponding toSomeDtoWithIdField
. I was thinking about how to drop theid
from the serializedvar
and thought that the following code surely wouldn't work because "GraphQL does not use Jackson annotations to drive JSON serialization/deserialization".But my colleague tried that anyway and to my surprise, it worked :-) That is, in my test case the
id
is not serialized intovar
while in the main flow theid
is serialized to the output type. My hypothesis is that while in the normal flow spring-grqphql uses some custom serializer,GraphQlTester
uses Jackson.Questions
GraphQlTester
use the same serializer as the main flow?(This question can be read as a sort of reverse of #521)
The text was updated successfully, but these errors were encountered: