Mocking Network Responses for tests

[scottasoutherland]

Question

We are in the process of trying to transition from Apollo 0.5.X to 1.0.X , and we're running into some difficulty. Specifically in 0.5.X we had a set of XCUITests which created mocked JSON responses from Apollo objects and then used that to mock our server requests during the test. Specifically, we'd create an object of type GraphQLSelectionSet, call .jsonObject on it. JSON encode that value, and then use it in a mocked network response. For instance

let myQuery = MyQuery.Data(someResponse: .init(propertyOne: "Some String", propertyTwo: 10))
let stubbedResponse = myQuery.jsonObject
stubServerResponse(stubbedResponse)

However, when trying to do the same thing in Apollo 1.0 this doesn't work for a few reasons.

1. Mock objects don't fully turn objects into their JSON value when calling _selectionSetMockData for instance, an array of GraphQLEnums will remain an array of GraphQLEnums instead of converting each of those into their _jsonValue.
2. Even if you convert everything recursively and serialize that, you may still run into failures because not every key is set. You could theoretically avoid this by forking the project and setting allowMissingValuesForOptionalFields but then you'd have to be very careful about how you create your mock objects to ensure that you are setting all the values you need to and if you forgot, debugging could be difficult.

So my question is, is there a way or suggestion to do this now in Apollo 1.0, i.e. to fully JSON encode either GraphQL Selection sets, or mock objects such that they can be decoded from the application as if they had come from the server directly ?

[calvincestari]

I think the biggest difference between the example you've showed and 1.0 is the missing property initializers on operations. We are working on a solution to this that will be released in the upcoming 1.1 version.

So my question is, is there a way or suggestion to do this now in Apollo 1.0, i.e. to fully JSON encode either GraphQL Selection sets, or mock objects such that they can be decoded from the application as if they had come from the server directly ?

Do you absolutely need a serialized JSON response or is that only used to get your tests a populated selection set? If the selection set is all you need then the new test mock objects do provide property initializers and are a much easier way to get to a valid selection set. Here is the test mock portion of the 1.0 migration guide and also the more general documentation on test mocks.

Even if you convert everything recursively and serialize that, you may still run into failures because not every key is set.

Depending on your use of GraphQL interfaces and unions this will still be possible even with serialized JSON responses.

[scottasoutherland]

Do you absolutely need a serialized JSON response or is that only used to get your tests a populated selection set? If the selection set is all you need then the new test mock objects do provide property initializers and are a much easier way to get to a valid selection set. Here is the test mock portion of the 1.0 migration guide and also the more general documentation on test mocks.

We are already using the mocks for our unit and snapshot tests. The problem is we have a 3rd test suite, which runs the actual app against a mocked server, so it does read in the responses from JSON as if it were the real server. But this code is all configured within the XCUITests. The way it used to work was creating the GraphQL Objects, serializing that out to json to the mock server inside the test setup code, and then serializing it back in inside the app during the test. Now this no longer works

[calvincestari]

@AnthonyMDev and I have spoken about this issue and it seems that we may be able to achieve this by changing DataDict from JSONObject to JSONEncodableDictionary. We going to look at whether it needs to be prioritized in on of the next minor releases.

@scottasoutherland as an answer to whether you can do this now in 1.0, it's unfortunately not possible. I'm also not sure whether the ability in 0.x was intentional or an unintended side-effect.

[scottasoutherland]

I think the conversion to JSONEncodableDictionary would probably only solve the first issue right ? I don't think all the keys would necessarily be set coming from a mock

[AnthonyMDev]

Yes, that's true, but that is part of the nature of the test mocks. We wanted you to only have to set the fields that are relevant for your test, and not be force to include stub data for fields that you weren't using. If your test throws and error because of a missing field, debugging that shouldn't be hard, it should be very obvious what value is missing and you just need to set them.

But this will actually be even easier for your case in 1.1. I'm working on adding generated initializers to the generated SelectionSet structs. Unlike test mocks, these would require you to actually provide values for all the necessary fields, so if you use those instead of the test mocks for tests where you need to create a complete, valid response, you should be good to go.

Between exploring the JSONEncodableDictionary and those initializers, that should address all of this.

[scottasoutherland]

So one of the issues i found once before, was i tried setting them directly to nil in some cases when they were nullable responses, and converting it to the JSONObject those got dropped. They only showed up if they were set to be non-nil . Looking at JSONEncodableDictionary i'm not sure that would be fixed. Perhaps it would via the initializers you are proposing, but i'm not so sure if they are still backed by the same data structure.

[scottasoutherland]

It doesn't look like .none ..some paradigm translated over to the mocks as far as I could tell.

[AnthonyMDev]

Ahh that's an interesting point. But wouldn't that also be the case with the previous approach in the legacy (0.5x) version? What was the behavior that you got from that solution that addressed this?

[AnthonyMDev]

I think the initializers could use GraphQLNullable for nullable parameters, and then we could keep track of this. However that's not really the ideal API for all other use cases... hmmmm

It doesn't translate over to the Test Mocks elegantly right now.

I'll think more about how/if we can improve this.

[scottasoutherland]

But wouldn't that also be the case with the previous approach in the legacy (0.5x) version? What was the behavior that you got from that solution that addressed this?

Nope. it works correctly in 0.5.x because result map is type aliased like
public typealias ResultMap = [String: Any?] where as JSONObject is
public typealias JSONObject = [String: JSONValue] , so setting a value to nil removes it from the dictionary in 1.X, whereas in 0.5.x , setting it to nil set the value in the dictionary to nil.