Verifying Event-Based URL Requests on iOS (feat. Is Ad Tracking Actually Working?)

Since ad tracking is directly tied to revenue, it was necessary to verify before deployment whether code changes had broken existing requests. A Fake object that only checks whether a function was called couldn't verify actual URLRequest transmission, so a structure that directly intercepts network requests was built.

The core is CustomURLProtocol, based on URLProtocol. In startLoading(), the request URL is recorded to storage, and an arbitrary 200 response is returned to complete a test-only flow instead of an actual network call. This protocol is injected into the protocolClasses of the URLSessionConfiguration used for ad tracking, so it only operates in the test environment.

The biggest problem was that the App Target and UI Test Target run as separate processes. Since they can't share the same in-memory object, the SIMULATOR_SHARED_RESOURCES_DIRECTORY environment variable was used to create a file storage under the simulator's shared directory, configured so that the App and UI Test read and write the same file.

The storage was designed to check not just mere existence but the URL count as well. Catching errors such as duplicate ad loading or failure to load on re-exposure required a more specific judgment than contains.

Test execution was done via UI Test. Since reproducing actual user flows requires accessibilityIdentifier, identification rules for screen elements were also organized.

• Use type-name-based identifiers where possible, following the type name
• For basic types like UIView, follow the property name
• Divide into enums per ViewController, and place common elements in Common

Finally, test data was separated using Protocol + Dependency Injection instead of dynamic network responses. By separating the network implementation from the JSON file loading implementation, the UI Test was made to accurately verify only whether ad tracking occurred, based on stable fixed data.