I've been trying to intercept and stub/mock HTTP requests in Xcode 7 automated UI tests, using tools like OHHTTPStubs, with no luck.
Here's an example of how I am trying to capture any HTTP request using OHHTTPStubs in the setUp method of a UI test file:
override func setUp() {
super.setUp()
let matcher: OHHTTPStubsTestBlock = { (request) -> Bool in
return true
}
OHHTTPStubs.stubRequestsPassingTest(matcher) { (response) -> OHHTTPStubsResponse! in
return OHHTTPStubsResponse.init()
}
}
Is there something about the way that UI testing works that prevents this? has anyone been able to achieve this?
As Martijn correctly pointed out, because of how UI tests work, you cannot directly interact with the app at runtime, so any HTTP mocking or manipulation of things like NSUserDefaults
in a XCUITestCase
will not affect your app.
If you really need to be able to mock HTTP or setup & teardown your apps environment for specific UI tests, you will need to set launch arguments or launch environment variables before launching the app in the setUp()
method of a XCUITestCase
and then modify your app code to read the launch arguments or environment variables and bootstrap the test environment.
Example TestCase
class MyTestCase: XCTestCase {
/**
Called before each test in this test case.
*/
override func setUp() {
super.setUp()
let app = XCUIApplication()
app.launchArguments = [ "STUB_HTTP_ENDPOINTS" ]
app.launch()
}
}
Example AppDelegate
func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObject: AnyObject]?) -> Bool {
#if DEBUG
if (NSProcessInfo.processInfo().arguments.contains("STUB_HTTP_ENDPOINTS")) {
// setup HTTP stubs for tests
}
#endif
return true
}
Note: In order to use an HTTP mocking framework like OHHTTPStubs
in this example, the stubbing code and any JSON fixtures you need to use will all need to be in your app target, not the test target.
This is a very useful thread to read on the topic: https://github.com/AliSoftware/OHHTTPStubs/issues/124
UI tests are ran in a separate instance from your application. While the classes from the application might be available to you, they are merely a copy.
In your application you can detect if you're running in UI testing mode with solutions provided here: How to detect if iOS app is running in UI Testing mode
I personally went with the launchEnvironment
solution mentioned in the original post; my setUp looks like this:
override func setUp() {
super.setUp()
let app = XCUIApplication()
app.launchEnvironment["TEST"] = "1"
app.launch()
}
And one of my singleton instantiators (called RealmManager
) looks like this (for instantiating a Realm database):
func realm() -> Realm {
let dic = NSProcessInfo.processInfo().environment
if dic["TEST"] != nil {
return try! Realm(configuration: Realm.Configuration(inMemoryIdentifier: "test"))
}
return try! Realm()
}
If you dislike the duplication, but you're probably already duplicating XCUIApplication().launch()
anyway, you can always make a custom test case class that extend XCTestCase
, override the setUp there with this addition and then use that in all your test classes.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With