Apollo-ios: How to mock and stub responses for UI tests?

[teerayuthton]

Hi guys, I read this issue #188 already, But i don't understand how to user ApolloClientProtocol to inject responses while i running ui test. Could you explain me more or some example.

Sorry for my english.
Thank you.

[designatednerd]

So #188 ApolloClientProtocol are coming at this from two different angles.

ApolloClientProtocol basically allows you to create your own implementation of ApolloClient which you're the puppetmaster for - you look at the incoming queries and then return data directly. It basically means that instead of using ApolloClient directly, you create your own MockApolloClient which conforms to ApolloClientProtocol, then hand that in to whatever else you're using. Basically you can look at the outgoing queries and say "OK this query wants this data" and hand it straight back without ever going to anything resembling the network.

188 is talking more about using an NSURLProtocol to intercept queries and return pre-populated data. This happens wayyyyy further down, once things have hit URLSession. You can see an example of this in MockURLSession in our tests.

Does that help?

[jacks205]

Is there any experience in setting up a local server to handle these requests rather than doing it locally? We're hitting a point where there's tons of local mock responses and we need a separate app target to run UI tests.

I'm using a mock of NetworkTransport to deserialize mock responses based on queries/mutations.

[designatednerd]

Yeah, that's pretty much what we're doing in the tests for this repo. If you do that you can just point it at localhost and avoid having to use a mock.

[designatednerd]

@teerayuthton @jacks205 Any further questions, or do y'all mind if I close this one out?

[teerayuthton]

@designatednerd
I don't understand your suggestion, My experience for coding ios UI Test.
I coding only action with accessibility and create local server
For example is

      func test_a1_filup_address() {

      let app = XCUIApplication()

      let pathaddress = "/v1/graphql"

      //Create local host. When api request include path "/v1/graphql" response will return json from file name
      //combine_address_for_onboarding.json"
      self.createlocalhostWith(localhost: self.localhostServer,
                              partDomain: pathaddress,
                    mockresponsefilename: "combine_address_for_onboarding.json")

      //Check title
      XCTAssertTrue(app.staticTexts["Are you at your store?"].exists,"Popup title should be Are you at your store?")

I only touch on UITest target and change Api Domain

      urlRequest = URLRequest(url: URL(string: "http://mydomain.com/)!)

      if ProcessInfo.processInfo.arguments.contains("UITESTTESTSERVER") {
            urlRequest = URLRequest(url: URL(string: "http://localhost/")!)
      }

My question is how i check response body from apollo request for separate each test with correctly mock response?
And how to adapt your concept to use with my test?

[designatednerd]

OK that's a different approach than catching things using the ApolloClientProtocol - you're returning things directly from a localhost server that you control, which makes things a lot simpler.

What it sounds like is that you'd need to set up your localhost separately at the beginning of each test. That way you can control what's coming back from the server for every single request. Does that make sense?

[teerayuthton]

Yes. I do it right now, But it different with graphQL because my local host can detect only different Url path, But graphQL i can't detect from request body.

[Dilip-M]

Hi @teerayuthton @designatednerd ,

Hope you both are doing good!

I'm a QA Automation Engineer, Currently i'm also trying to set up the mock server for my graphql responses. After reading the thread , I'm confused with the approaches. Kindly advise me which approach i should start for the implementing the graphql mock server setup?

[designatednerd]

@Dilip-M You're probably confused becuase we're talking about two different strategies.

Strategy 1: Use a server you're running on localhost that you can set up to return specified data per query.

This could involve something like @teerayuthton is using, where you say "When I hit this URL, return this data." This could be something where on the local server itself, you add something to see what query is being put in and return specified data for that query.

The advantage of this is that everything is completely outside the application, so you can more easily use it to test your UI without having to alter any of your application code.

Strategy 2: Implement your own version of ApolloClientProtocol to intercept calls within the iOS application itself.

In this case, instead of using a raw ApolloClient that goes out and makes network calls, you implement all the methods on ApolloClient, and use the information coming into those methods to determine what query is being made, and what data should be returned.

The advantage of this is that you have more fine-grained control of what data is returned for which query without having to even hit a local server.

The disadvantage of this is that if you're using XCUI tests, you will wind up with test code in your application.

Does that help explain a bit of the difference between the strategies and some examples of how you could use each one?

[Dilip-M]

Thanks @designatednerd 👍 Now, I'm able to differentiate both Strategies. I'm planning to start with the Strategy 2 , do you have any implementation procedure/steps available?

[designatednerd]

We don't have specific ones because that method allows you to take it in any number of directions. The most basic thing I would say is that you'd need to create another class that conforms to ApolloClientProtocol and use that class in place of ApolloClient within your application code. Then within the new class, you can intercept and look at whatever queries are coming in through the various methods the protocol requires you to override, and manually pass data back that way.

[Dilip-M]

Thanks again @designatednerd , I'm just kick staring and no clue how things will work for me.