RFC: Revisiting Apollo Client's testing approach

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.

[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.

[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.