feat req: Improve "No more mocked responses for the query" message

[FernandoBasso]

It would be very nice and useful if instead of a simply returning "No more mocked responses for the query", the message would also point out where (or how) the mocked response differ from what is expected.

In my (so far) brief experience with MockedProvider, that message generally arises from different mocked responses, different variables, and things like those. Also, when you refetch or fetchMore, and you don't provide the "extra" mocked responses.

I have seen lots of issues and questions about this message, and I believe a more specific message would be of great help.

[KosnIre]

@FernandoBasso I'm staring at one of these right now. You mention adding something in particular for the refetch case. What do I need to add there?

It's most frustrating to me that when the MockedProvider reports these issues, I have no way to debug them. If I could get some hook into the MockedProvider, I could at least log some console lines to try and figure it our for myself.

[FernandoBasso]

So, my rationale is that we have a normal query and mutation, and we can mock them. But then, we can also have refetch and fetchMore, and for each time we invoke them, we must have one more mocked response. If we have a Query followed by two fetchMore invocations, we must provide three mocked responses.

Another situation is when our mocked query is different (params, fields, etc) from the original query, and again, the same "no more mocked responses for the query" message is displayed. But in such cases we have no way to know where in the code our mocked response differs from the original one.

It would be very helpful if the message were more specific, saying that our mocked response differs (and where) instead of just saying there are no more mocked responses.

So, @KosnIre, I don't mean only for refetch, but for all cases where that default message is currently triggered.

As a side note, I have invested lots of time trying to mock very large responses. I guess such improvement would help immensely in such cases as well.

[KosnIre]

Ok thanks @FernandoBasso. I guess my wording was poor, but you have helped fix my issue (at least this one-- I would love to see some more specific errors like you suggest here).

we must provide three mocked responses.

I'm still new to using Apollo, so I did not even realize that I had to add more mocked responses for each request the test-case makes! I don't think the documentation does a very good job of explaining this. I was able to find where the code removes mocked responses as it uses them.

That behavior seems strange to me, but I guess that is off-topic. Better error messages would have helped me figure that out sooner.

I guess the hard part about showing the differences is that the MockLink doesn't explicitly know which one is supposed to match. So you would have to make a guess, maybe based on the query name.

[KyleBastien]

I just ran across a really bad version of this, that having better logs or reasoning would have helped a lot.

Basically my operation's variables was this object:

{
  search: undefined
}

But my mock variables was this object:

{}

The best part is that if you JSON.stringify those two objects, they both show as {}, which makes this even harder to debug. But, lodash says they're not equal objects.

Having something that says something like:

No more mocked response for the query, the reason is that the variables from your operation and the mock responses do not match. You do have a mock query though with the same name as this operation, the variables for that mock query is ${variables}, which differs from the operation variables which looks like ${operationVariables}.

Would be SO HELPFUL!

[chanceeakin]

Looks like this is the line you're looking for. Gonna try to draw up a PR for it in a few days:

react-apollo/src/test-links.ts

Line 77 in 3381ade

if (!response || typeof responseIndex === 'undefined') {

[hwillson]

To help provide a more clear separation between feature requests and bugs, and to help clean up the feature request backlog, React Apollo feature requests are now being managed under the https://github.com/apollographql/apollo-feature-requests repository.

Migrated to apollographql/apollo-feature-requests#115.