Allow MockedProvider to accept a schema plus resolver mocks.
Migrated from: apollographql/react-apollo#3108
This feature would resolve a number of issues. I think the root of this feature request would be to support resolvers as functions that can accept variable arguments, rather than requiring the variables to be hard-coded in the mocks themselves. Maybe there's a better approach than just taking the interface from graphql-tools, but providing a similar feature would be incredibly beneficial.
Here are a few adjacent issues which could be resolved with something like this:
- https://github.com/apollographql/apollo-feature-requests/issues/89 - a function can generate dynamic variables
- https://github.com/apollographql/apollo-feature-requests/issues/206 - a function could accept any variables/ignore them
- https://github.com/apollographql/apollo-feature-requests/issues/173 (this one is a behavioral issue that could be resolved with a functional interface)
- https://github.com/apollographql/apollo-feature-requests/issues/115 - datetimes cause some issues and require string-literal work-arounds
My current work-around is to define mock data, and then iterate over every possible value to create a large array of mocks that handles all possible values. Note that some of the above issues are not completely resolved with this work-around and require their own work-arounds as well.
I understand why there may be some hesitance here because there may be compatibility issues between some of these libraries. However, the alternative in userland is a sad mess of complex test data + mock generation which I'd argue is more confusing test setup than a function.
I wonder if there's a simple way to accommodate a functional interface like the one mentioned in this issue.
I've been using an approach similar to this which works really well for me. I think it solves all the problems brought up in this issue so far: https://medium.com/free-code-camp/a-new-approach-to-mocking-graphql-data-1ef49de3d491
I've used that approach as well and I agree that it's a better interface than the MockedProvider, and was actually the only way to mock the schema a few years back. However, I've found that interface to to be unstable between differing apollo dependencies, and upgrading apollo versions was challenging.
I assume these sorts of challenges are part of the reason we have a MockedProvider in the first place, in addition to its simplicity. This is why I'd like for the apollo team to consider improvements to the MockedProvider itself.
Hi all ๐ You may be interested in the RFC I've just opened for a new schema-driven testing utility: https://github.com/apollographql/apollo-client/issues/11705
It doesn't directly resolve this feature request, but I believe it has certain DX advantages over a provider-style API and would love to hear your thoughts over on that issue :)
@alessbell thanks for sharing and nice that this issue got an update! (i completly forgot about that)