Testing a live API call (or not)?

[bux225]

I have an app that is very dependent on multiple API calls based on Auth2.0. As well, the API response payload is decoded into my model with obviously a very specific structure. Below is an example of obtaining a JWT bearer using the user- inputted credentials.

Thus, it is important to me to be able to test at least two scenarios:

1. A happy path 200 response from the API and check the structure of the response fits my model. This ensures I don't break the model underneath accidentally AND gives me pinpoint troubleshooting if the API itself changes their payload
2. A 401/403 unauthorized handling in order to ensure I present a user with a nice fail UX if they put in bad credentials

The dependency model in TCA doesn't seem to work for me as it tests the action OK but none of the above

This was my action before I tried using Dependencies:

    case .authenticate:
      return .run { [state = state] send in
        let url = URL(string: "https://account.maxar.com/auth/realms/mds/protocol/openid-connect/token")!
        var request = URLRequest(url: url)
        request.httpMethod = "POST"
        request.setValue("application/x-www-form-urlencoded", forHTTPHeaderField: "Content-Type")
        request.httpBody = "username=\(state.username)&password=\(state.password)&client_id=\(state.clientId)&grant_type=password".data(using: .utf8)
        //print(String(decoding: request.httpBody!, as: UTF8.self))
        let (data, body) = try await URLSession.shared
            .data(for: request)
        var code = 0
        var response = MGPAuthResponse()
        if let http = body as? HTTPURLResponse {
            code = http.statusCode
            if http.statusCode == 200 {
                response = try JSONDecoder().decode(MGPAuthResponse.self, from: data)
            }
        }
        await send(.setAuthResponse(response))
        await send(.setHttpStatusCode(code))

[mbrandonw]

Hi @bux225, this is a good question, thanks for bringing it up!

First, if you want to write a test that exercises your full API stack, then it is absolutely possible to do with TCA's testing tools. You would just construct your store like this:

let store = Store(initialState: Feature.State()) {
  Feature()
} withDependencies: {
  $0.apiClient = .liveValue
}

This will now execute your real life API networks when running tests. Alternatively, you can write a test against your live API client dependency without touching TCA at all since that is the code you want to make sure is hooked up correctly.

However, this is almost always not what you actually want to do. Such a test can now only run when you have internet connectivity, when your server is stable, and when you can actually predict what the server will send back. Such tests are very difficult to write and tend to be very flakey, and many times we do not care about exercising the full end-to-end lifecycle of the request leaving the device and a response being delivered from the actual server.

A large portion of our tests are instead concerned with how the logic in the app behaves. So, the user taps a button, an effect executes to return some data, and then the feature reacts to that data. That flow can be done without every making a live network request, and that is why we mock network requests the majority of the time.

That doesn't mean testing the full end-to-end lifecycle isn't useful. It certainly can be done (as shown above), but it tends to be a smaller percentage of tests than the other kinds of unit tests.

As a side note, I'm a little confused with the effect you have shared. Why are you sending back the status code and response back into the reducer? Typically the reducer would only care about the actual data returned from the server, usually deserialized into a first class Swift data type.