RFC: Revisiting Apollo Client's testing approach

[hwillson]

We currently recommend using the MockedProvider and associated API approach to testing applications built using Apollo Client. MockedProvider works well in a lot of cases, but can be difficult to manage as codebases increase in complexity due to its very rigid functionality, often unhelpful error messages, and boilerplate heavy nature.

To work around some of the current limitations of Apollo Client's recommended testing approach, the community has come up with some really interesting and more modern approaches to testing. A small sampling:

• https://zendesk.github.io/laika/
• https://github.com/mike-gibson/mock-apollo-client
• https://www.arahansen.com/testing-apollo-components-using-react-testing-library/
• https://www.robinwieruch.de/react-apollo-client-testing/
• https://medium.com/free-code-camp/a-new-approach-to-mocking-graphql-data-1ef49de3d491

To make sure Apollo Client is giving developers the tools they need to develop robust and effective client applications out of the box, we're working on a new testing approach that will become part of the core library.

We'll share more details about these plans shortly, but would love to hear from the community regarding their biggest complaints about Apollo Client's existing testing functionality, what people would like to see fixed or handled differently, and hear about recommendations of community approaches you prefer.

[radfahrer]

By far the biggest problem with MockedProvider is that it is not composable. It would be convenient to be able to wrap all fixtures with a MockProvider that has mocks for all the default data, and to be able to wrap a specific fixture with an additional MockProvider to override the mocks for just that fixture/test.

[jpvajda]

I found Relay's approach with the MockPayloadGenerator appealing.

One of the patterns you may see in the tests for Relay components: 95% of the test code is the test preparation—the gigantic mock object with dummy data, manually created, or just a copy of a sample server response that needs to be passed as the network response. And the remaining 5% is actual test code. As a result, people don't test much. It's hard to create and manage all these dummy payloads for different cases. Hence, writing tests is time-consuming and tests are sometimes painful to maintain.

[jpvajda]

#8900

[jpvajda]

apollographql/apollo-feature-requests#245

[jpvajda]

#7591

[jpvajda]

#7081

[jpvajda]

#6383

[jpvajda]

apollographql/apollo-feature-requests#233

[jpvajda]

apollographql/apollo-feature-requests#221

[jpvajda]

apollographql/apollo-feature-requests#205

[jpvajda]

apollographql/apollo-feature-requests#206

[jpvajda]

apollographql/apollo-feature-requests#203

[jerelmiller]

apollographql/apollo-feature-requests#351

[jerelmiller]

https://techblog.assignar.com/dos-and-donts-of-testing-apollo/#do-mock-at-the-service-worker-level-

Referenced from #5917 (comment)

[revmischa]

I absolutely need the ability to wildcard variables for mocked requests. As one example I have a mutation where I generate an UUID on the client-side and send it to the backend as a unique identifier. There is no possible way to mock this without mocking the uuid library or something similarly preposterous.

Best part is that this is already partially implemented in https://github.com/insidewhy/wildcard-mock-link so it can't be that much effort to include.

[jerelmiller]

apollographql/apollo-feature-requests#317

[lifeiscontent]

@hwillson on this note, it would be really nice to have an option to MockedProvider to clear results after a single render I'm using MockedProvider in https://github.com/lifeiscontent/storybook-addon-apollo-client which is a tool that allows people to render full page components with apollo in storybook.

but there are some unexpected side effects like when the user changes between stories, the previous results from another story are cached, and a cache is definitely needed to do type policy and dataIdFromObject lookups

[sjwilczynski]

What we have used with pretty good success in parts of Microsoft is apollo-mock-client and related payload-generator. They are mostly ports of counterpart Relay's functionality and similarly as mentioned before in this thread, we find such API more convenient to use than mocked provider, as you only need to think about mocking per type level. Great thing is that these tools can be very nicely used both in unit tests and in Storybook, which we also added more details on in another testing tools package we own. I would be happy to share more details in case anyone is interested

[alessbell]

Thanks to those who've provided feedback/shared approaches they're currently using in this thread! It's great to see so many different ideas and approaches in the testing space.

I've picked up this issue and am working on our own Apollo Client tool for schema-driven testing. Stephanie Saunders¹ gave a great talk at GraphQL Conf in September that begins with an overview of the front-end GraphQL testing landscape and concludes with how front-end teams think about testing at Coinbase. If anyone wants a primer on what I mean by "schema-driven testing", I'd recommend it as a good place to start.

The API we're considering will allow developers to write mock resolvers and generate an executable schema that can be passed to Apollo Client's SchemaLink, with a default set of resolvers that can be updated inline in your tests. This SchemaLink with mock executable schema would serve as the terminating link in your testing environment so components can be rendered within a regular old ApolloProvider and mock data is returned from SchemaLink without network requests.

This will allow developers to test the rest of their link chain, specify defaults for scalar values and reap the benefits of added flexibility that comes with not having to define and update static response mocks. For example, if a field is added to a query, an existing test will continue passing without complaint: default scalar values will allow the component to render some e.g. default string, and if the new field should return a specific value the resolver can be mocked inline in the test. I'll have more on this with some examples soon.

As for MockedProvider, it's not going anywhere. In fact, we're shipping two improvements in 3.9 that you can already test out in the alpha (npm i @apollo/client@next): the ability to dynamically match mocks (#6701) and the ability to re-use mocks (#11178).

Footnotes

1. I can't find Stephanie's GH handle but would have loved to give a shout out :) ↩

[alessbell]

Hi all 👋 I've created an RFC (#11705) for the schema-driven testing work I described above.

I'm going to close this issue out, since that RFC is a better place to discuss work currently underway, and any other testing ideas should be opened as feature requests over on our feature requests repository. Thanks!

[github-actions]

Do you have any feedback for the maintainers? Please tell us by taking a one-minute survey. Your responses will help us understand Apollo Client usage and allow us to serve you better.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
For general questions, we recommend using StackOverflow or our discord server.