Getting started with mocking networking in UI-tests on iOS

It is important to have stable unit-tests and UI-tests since no-one wants to encounter failures in tests which happen non-deterministically. Many of the iOS apps rely on networking, and therefore the content depends on what is fetched from servers. The last thing what we want to see is that an API outage or instability affects UI-tests. This time we’ll take a look at how to mock networking in UI-tests which differs from mocking networking in unit-tests since the whole app is going to be running as is and is controlled by a separate UI-testing runner app. A while ago I also covered unit-testing part in Testing networking code with custom URLProtocol on iOS, please take a look at that post for more information since we’ll be using the same custom URL protocol approach.

The main difference between unit-tests and UI-tests is that with unit-tests Xcode injects the unit-testing code into the app and then runs tests. UI-testing on the other hand rely on a separate test runner app which uses accessibility APIs for driving the user-interface in the app. This means that our network mocking code needs to be bundled with the app when we build it. The approach we are going to use is setting up a separate “UITestingSupport” Swift package, which is included only in debug builds. This library contains mocked data and configures the custom URL protocol and handles any network requests. Please see Linking a Swift package only in debug builds for more information on how to only link a package in debug builds.

I’ll be using a sample app “UITestingNetworking” for demonstrating how to set it up. The app has an app target and a local Swift package with a name “UITestingSupport”.

Xcode project layout with UITestingSupport package.

The first piece of the “UITestingSupport” package is a custom URLProtocol. All it does is providing a way to return either error or URLResponse and Data for a URLRequest. It is a simplified protocol. In an actual app we would want to control which requests are handled by it and which are not. Either because it is way too difficult to mock all the network request in all the tests at first, or we might also want to have some tests using an actual data coming from servers.

	final class UITestingURLProcotol: URLProtocol {
	override class func canInit(with request: URLRequest) -> Bool {
	return true // TODO: only return true for requests we have mocked data
	}

	override class func canonicalRequest(for request: URLRequest) -> URLRequest {
	return request
	}

	struct ResponseData {
	let response: URLResponse
	let data: Data
	}

	static var responseProvider: ((URLRequest) -> Result<ResponseData, Error>)?

	override func startLoading() {
	guard let client else { fatalError() }

	if let responseProvider = Self.responseProvider {
	switch responseProvider(request) {
	case .success(let responseData):
	client.urlProtocol(self, didReceive: responseData.response, cacheStoragePolicy: .notAllowed)
	client.urlProtocol(self, didLoad: responseData.data)
	client.urlProtocolDidFinishLoading(self)
	case .failure(let error):
	client.urlProtocol(self, didFailWithError: error)
	client.urlProtocolDidFinishLoading(self)
	}
	}
	else {
	let error = NSError(domain: "UITestingURLProcotol", code: -1)
	client.urlProtocol(self, didFailWithError: error)
	}
	}

	override func stopLoading() {}
	}

view raw UITestingURLProtocol.swift hosted with ❤ by GitHub

The second piece of the library is a UITestingNetworkHandler class which the app code will call, and it configures the custom URLProtocol and starts providing responses based on the “responseProvider” callback.

	public final class UITestingNetworkHandler {
	public static func register() {
	URLProtocol.registerClass(UITestingURLProcotol.self)

	UITestingURLProcotol.responseProvider = { request in
	guard let url = request.url else { fatalError() }
	switch (url.host, url.path) {
	case ("augmentedcode.io", "/api/example"):
	let response = HTTPURLResponse(url: url, statusCode: 200, httpVersion: nil, headerFields: nil)!
	let data = "MyMockedData".data(using: .utf8)!
	return .success(UITestingURLProcotol.ResponseData(response: response, data: data))
	default:
	fatalError("Unhandled")
	}
	}
	}
	}

view raw UITestingNetworkHandler.swift hosted with ❤ by GitHub

Simple example of providing response for a URLRequest.

The example above just handles one network request. For larger apps we probably want to have more component based implementation here since this file would otherwise grow a lot based on how many cases we want to handle. Another thing to note is that in some tests we want to mimic network request failures and in others successful requests but with different response data. This is not shown above, but can be implemented by providing the expected configuration flag through environment variables. XCUIApplication has a launchEnvironent property what we can set and then reading that value in the UITestingNetworkHandler with Process environment property. I’m thinking something like “MyAppAPIExampleResponseType” which equals to a number or some identifier.

The last piece is to call the register code when we are running the app in UI-tests.

	@main
	struct UITestingNetworkingApp: App {
	var body: some Scene {
	WindowGroup {
	ContentView()
	#if DEBUG
	.onAppear(perform: {
	guard CommandLine.arguments.contains("–uitesting") else { return }
	UITestingNetworkHandler.register()
	})
	#endif
	}
	}
	}

view raw App.swift hosted with ❤ by GitHub

Calling register only in debug builds and when a launch argument is set by the runner app.

And finally, an example UI-test which taps a button which in turn fetches some data from the network and then just displays the raw data in the app.

	class UITestingNetworkingUITests: XCTestCase {
	override func setUpWithError() throws {
	continueAfterFailure = false
	}

	func testExample() throws {
	let app = XCUIApplication()
	app.launchArguments = ["–uitesting"]
	app.launch()
	app.buttons["Load Data"].tap()
	XCTAssertEqual(app.staticTexts.element.label, "MyMockedData")
	}
	}