Testing DataRequests

How can I test DataRequest properties after creation, asserting url, method, headers, and httpData after an RequestAdapter is used (for example adding additional headers), but without making the request?

let dataRequest = session.request(_:method:, parameters: .... )

I can use request.convertible.asURLRequest() but it doesn't contains all data, because the RequestAdaptor is not yet used. Is there an API for "simulation" to get the final URLRequest?

There are a few different approaches you can take with varying fidelity.

First, and easiest, is that you can use the Interceptor type to compose multiple adapters, retriers, and interceptors together and call the adapt and retry methods manually. That should let you specifically test various types of incoming URLRequest to ensure the adapters modify them correctly. Retriers are harder to test in this way since they require a Request and a Session to look at to determine whether or not to retry, but you could always modify your retriers to have a simpler entry method for testing.

Second, you can modify your Session to not start Requests automatically and then use the normal request(...) methods to create the Request values and test their state. Without automatic state you should get a URLSessionTask in the Request's tasks array (and lastTask for only the latest task created), as well as the requests array, which contains all the URLRequests created for the Request through the various adapters. I mention both tasks and requests because URLSession modifies the URLRequest used to create the task internally, so it's not part of the requests array. Instead you'll need to inspect the tasks to see what requests were used for the tasks themselves. However, those may not be created until the task is actually resumed. So you'll need the last strategy.

Finally, you can use real or stubbed networking (using a library like OHHTTPStubs) to fully simulate your network calls through actual retry and inspect all of the relevant state along the way. This should also let you inspect the URLRequests generated by URLSession and inspect their state. Locally stubbing would also let you see what would go out over the network for full inspection.

Thanks for the detailed answer. For the moment I will go with option 1. I only need to add some tests for the user agent and some special headers added by the bot defender. But in the future I will check also how networking stubbing would work, seems the best way for testing the whole integrated chain.