You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since SelectionSets can contain arbitrarily complex logic, it would be nice to have ways to write unit tests for them1.
That begs the question of what API/form should this hypothetical testing utility have?
Typically JSON decoders (which are let's say somewhat similar to SelectionSets) are tested in two ways:
You can pass in a string literal JSON, then decode it with a decoder and assert that it matches the expected Elm datastructure.
The second option is to fuzz the datastructure, then run roundtrip through the encoder and decoder and make sure that you have the original datastructure.
With SelectionSets the issue is that a selection set generates both the query and the decoder for the response. The response JSON depends on the query with fairly unpredictable hash aliases. This would make the literal approach rather difficult and brittle.
Another approach that might work is to essentially build a mock GraphQL server, then the test validates that the mock server schema matches the query schema and uses it to decode the final elm datastructure.
I also wonder if the GraphQL schema isn't rich enough to automatically generate Fuzzers for the input datastructure; that would allow us to quite easily build invariant tests over our SelectionSets.
I guess finally there might be some approach with code generation, where a mock data provider could be generated in a type-safe sort of way... But what exact shape that would have, I don't quite know.
Footnotes
At my work, roughly half of the whole application basically deals with SelectionSets, so this is pretty important for us. Our API is very generic and the front-end needs to do a lot of work to get it to look like the types we can actually render. ↩
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Since
SelectionSet
s can contain arbitrarily complex logic, it would be nice to have ways to write unit tests for them1.That begs the question of what API/form should this hypothetical testing utility have?
Typically JSON decoders (which are let's say somewhat similar to SelectionSets) are tested in two ways:
You can pass in a string literal JSON, then decode it with a decoder and assert that it matches the expected Elm datastructure.
The second option is to fuzz the datastructure, then run roundtrip through the encoder and decoder and make sure that you have the original datastructure.
With SelectionSets the issue is that a selection set generates both the query and the decoder for the response. The response JSON depends on the query with fairly unpredictable hash aliases. This would make the literal approach rather difficult and brittle.
Another approach that might work is to essentially build a mock GraphQL server, then the test validates that the mock server schema matches the query schema and uses it to decode the final elm datastructure.
I also wonder if the GraphQL schema isn't rich enough to automatically generate Fuzzers for the input datastructure; that would allow us to quite easily build invariant tests over our SelectionSets.
I guess finally there might be some approach with code generation, where a mock data provider could be generated in a type-safe sort of way... But what exact shape that would have, I don't quite know.
Footnotes
At my work, roughly half of the whole application basically deals with SelectionSets, so this is pretty important for us. Our API is very generic and the front-end needs to do a lot of work to get it to look like the types we can actually render. ↩
Beta Was this translation helpful? Give feedback.
All reactions