How one tests http requests in iOS 8? - ios

In ruby I used to test http requests with vcr gem which recorded the request so the tests didn't send request to real host. Is there anything like this in iOS8 world?
The requests I want to test really need to be recorded since those requests may be outdated in some time and will return some other response
P.S. It would be great if it was some default Apple/iOS approach/library like XCTest for testing in general

What you want is something like OHHTTPStubs or Nocilla or AMY server. All of them essentially use NSURLProtocol to intercept your request and allow you to designate a response. We used OHHTTPStubs but pick the one with the feature set closest to your use case.
Here's an example of an OHHTTPStubs implementation in a unit test for a service that talks to a single REST endpoint:
NSString *loadRoomJSON = #{ #"key" : #"value" }; /* some JSON */
NSNumber identifier = #1;
[OHHTTPStubs stubRequestsPassingTest:^BOOL(NSURLRequest *request) {
NSString *url = [NSString stringWithFormat:#"v1/user/%#/room", identifier];
XCTAssert([request.URL.relativePath containsString:url], #"Expected certain URL");
return YES;
} andRespond:^OHHTTPStubsResponse *(NSURLRequest *request) {
return [OHHTTPStubsResponse responseWithJSONObject:loadRoomJSON statusCode:200 headers:nil];
}];
XCTestExpectation *loadPromise = [self expectation:#"Room loaded"];
[service loadRoomOnSucceed:^(Room *room) {
// Do your asserts here. For us, the JSON is mapped to an object
// so for example you could assert that the object is mapped correctly
[loadPromise fulfill];
} onFail:^(NSError *error) {
expect(error).to.beNil();
}];
[self waitForExpectationsWithTimeout:1.0 handler:^(NSError *error) {
expect(error).to.beNil();
}];
In reality our tests are shorter since we write wrapper/helpers to make it read better so this is an exploded-out version. Should give you the general idea. OHHTTPStubs (if you use it) has helper functions to load responses directly from files as well.

Im not sure if I understood you correct. But if I understand you right, you should be able to use XCTest to test your request and response.
class Tests:XCTestCase{
func testing(){
var expectation = self.expectationWithDescription("Your request")
var url = NSURL(string: "http://yourUrl.com")
let task = NSURLSession.sharedSession().dataTaskWithURL(url!) {(data, response, error) in
if let httpRes = response as? NSHTTPURLResponse {
println("status code=",httpRes.statusCode)
//200 means OK
if httpRes.statusCode == 200 {
println(NSString(data: data, encoding: NSUTF8StringEncoding))
}
}else{
println("error \(error)")
}
}
}
}

Related

Writing Unit Test with asynchronous code in IOS

I need to test my Api calls response but before the block return Unit test got completed
how can i test my APIs
You can use XCTestExpectation for that.
XCTestExpectation *apiCallExpectation = [self expectationWithDescription:#"APICall"];
[apiService apiCall:^(BOOL success) {
XCTAssert(success);
[apiCallExpectation fulfill];
}];
[self waitForExpectationsWithTimeout:5 handler:^(NSError *error) {
[apiCallExpectation closeWithCompletionHandler:nil];
}];
At first, you don't need to call the actual API in unit testing, It shall to be independent and quicker to be completed. This shall be part of integration testing.
Regarding your question, I think you need to use Expectations, and Waiter. Check the following:
func testExample() {
let responseExpectation = expectation(description: "response")
// Your API Call shall be here
DispatchQueue.main.async {
// When you get the response, and want to finalize the expectation
responseExpectation.fulfill()
}
let result = XCTWaiter.wait(for: [responseExpectation], timeout: 15) // ex: 15 seconds to wait for the response for all expectations.
// result possible values are:
//all expectations were fulfilled before timeout.
.completed
//timed out before all of its expectations were fulfilled
.timedOut
//expectations were not fulfilled in the required order
.incorrectOrder
//an inverted expectation was fulfilled
.invertedFulfillment
//waiter was interrupted before completed or timedOut
.interrupted
}
Following is an example i am performing test case on a search api. you need to declare expectation and it will get fulfil once it's done.
func test_UpdateShowSearch_Result() {
let promise = expectation(description: "Status code: 200")
let searchAPI: SearchShowApi = SearchShowApi()
searchAPI.search(query: "") { (statusCode, tvShows ,error) in
if statusCode == 200 {
// reload table
promise.fulfill()
} else if (statusCode == 204){
// show no content
XCTFail("Status code: \(statusCode)")
}
else{
XCTFail("Error: \(String(describing:error?.localizedDescription))")
return
}
}
wait(for: [promise], timeout: 10)
}

Waiting for network call to finish

What I'm trying to achieve is to make a network request and wait for it to finish, so that I can make a decission what should be apps next step.
Normally I would avoid such solution, but this is a rare case in which codebase has a lot of legacy and we don't have enough time to apply necessary changes in order to make things right.
I'm trying to write a simple input-output method with following definition:
- (nullable id<UserPaymentCard>)validCardForLocationWithId:(ObjectId)locationId;
The thing is that in order to perform some validation inside this method I need to make a network request just to receive neccessary information, so I'd like to wait for this request to finish.
First thing that popped in my mind was using dispatch_semaphore_t, so I ended up with something like this:
- (nullable id<UserPaymentCard>)validCardForLocationWithId:(ObjectId)locationId {
id<LocationsReader> locationsReader = [self locationsReader];
__block LocationStatus *status = nil;
dispatch_semaphore_t sema = dispatch_semaphore_create(0);
[locationsReader fetchLocationProviderStatusFor:locationId completion:^(LocationStatus * _Nonnull locationStatus) {
status = locationStatus;
dispatch_semaphore_signal(sema);
} failure:nil];
dispatch_semaphore_wait(sema, DISPATCH_TIME_FOREVER);
return [self.paymentCards firstCardForStatus:status];
}
Everything compiles and runs, but my UI freezes and I actually never receive sempahore's signal.
So, I started playing with dispatch_group_t with exactly the same results.
Look like I might have some problems with where code gets executed, but I don't know how to approach this and get the expected results. When I try wrapping everything in dispatch_async I actually stop blocking main queue, but dispatch_async return immediatelly, so I return from this method before the network request finishes.
What am I missing? Can this actually be acheived without some while hacks? Or am I trying to fight windmills?
I was able to achieve what I want with the following solution, but it really feels like a hacky way and not something I'd love to ship in my codebase.
- (nullable id<UserPaymentCard>)validCardForLocationWithId:(ObjectId)locationId {
id<LocationsReader> locationsReader = [self locationsReader];
__block LocationStatus *status = nil;
__block BOOL flag = NO;
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
[locationsReader fetchLocationProviderStatusFor:locationId completion:^(LocationStatus * _Nonnull locationStatus) {
status = locationStatus;
flag = YES;
} failure:nil];
});
while (CFRunLoopRunInMode(kCFRunLoopDefaultMode, 0, true) && !flag){};
return [self.paymentCards firstCardForStatus:status];
}
I guess fetchLocationProviderStatusFor:completion:failure: calls those callbacks in main queue. That's why you get deadlock. It's impossible. We can't time travel yet.
The deprecated NSURLConnection.sendSynchronousRequest API is useful for those instances when you really can't (or just can't be bothered to) do things properly, like this example:
private func pageExists(at url: URL) -> Bool {
var request = URLRequest(url: url)
request.httpMethod = "HEAD"
request.timeoutInterval = 10
var response: URLResponse?
try! NSURLConnection.sendSynchronousRequest(request,
returning: &response)
let httpResponse = response as! HTTPURLResponse
if httpResponse.statusCode != 200 { return false }
if httpResponse.url != url { return false }
return true
}
Currently, your method causes work to be done on the main thread, which freezes the UI. Your solution works, but it would be best to change the method to include a completion block. Then, you could call the completion block at the end of the async block. Here's the example code for that:
- (void)validCardForLocationWithId:(ObjectId)locationId completion:(nullable id<UserPaymentCard> (^)(void))completion {
id<LocationsReader> locationsReader = [self locationsReader];
__block LocationStatus *status = nil;
[locationsReader fetchLocationProviderStatusFor:locationId completion:^(LocationStatus * _Nonnull locationStatus) {
status = locationStatus;
completion([self.paymentCards firstCardForStatus:status]);
} failure:nil];
}

Unit test case for call back methods ios

I have a following method in my app for which I need to write unit test cases.
Can anyone suggest how can I test whether the success block or error block is called.
- (IBAction)loginButtonTapped:(id)sender
{
void (^SuccessBlock)(id, NSDictionary*) = ^(id response, NSDictionary* headers) {
[self someMethod];
};
void (^ErrorBlock)(id, NSDictionary*, id) = ^(NSError* error, NSDictionary* headers, id response) {
// some code
};
[ServiceClass deleteWebService:#“http://someurl"
data:nil
withSuccessBlock:SuccessBlock
withErrorBlock:ErrorBlock];
}
You have to use expectations, a relatively recently introduced API. They were added to solve exactly the problem you are having right now, verifying callbacks of asynchronous methods are called.
Note that you can also set a timeout that will affect the result of the test (slow network connections for example can fire false positives, unless you are checking for slow connections of course, although there are much better ways to do that).
- (void)testThatCallbackIsCalled {
// Given
XCTestExpectation *expectation = [self expectationWithDescription:#"Expecting Callback"];
// When
void (^SuccessBlock)(id, NSDictionary*) = ^(id response, NSDictionary* headers) {
// Then
[self someMethod];
[expectation fulfill]; // This tells the test that your expectation was fulfilled i.e. the callback was called.
};
void (^ErrorBlock)(id, NSDictionary*, id) = ^(NSError* error, NSDictionary* headers, id response) {
// some code
};
[ServiceClass deleteWebService:#“http://someurl"
data:nil
withSuccessBlock:SuccessBlock
withErrorBlock:ErrorBlock];
};
// Here we set the timeout, play around to find what works best for your case to avoid false positives.
[self waitForExpectationsWithTimeout:2.0 handler:nil];
}

How to queue up batch operations in AFNetworking 2.0

I have this function which calls a GET method on AFHTTPRequestOperationManager:
var request:NSMutableURLRequest = ParseAPIClient.sharedClient.GET(className, parameters: parameters, success: { (operation:AFHTTPRequestOperation!, response:AnyObject!) -> Void in
if response.isKindOfClass(NSDictionary) {
self.writeJSONResponse(response, toDiskForClassWithName:className)
} else { NSLog("something happened") }
}, failure: { (operation:AFHTTPRequestOperation!, error:NSError!) -> Void in
NSLog("Request for class %# failed with error: %#", className, error)
})
This generates a request uses that request to create an AFHTTPRequestOperation. That operation is returned in that method along with a response to the request. The block passed into it writes the response to disk.
In my old AF1.x code, I would then use:
SDAFParseAPIClient.sharedClient.enqueueBatchOfHTTPRequestOperations:operations progressBlock:^(NSUInteger numberOfCompletedOperations, NSUInteger totalNumberOfOperations) {
} completionBlock:^(NSArray *operations) {
if (!toDelete) {
self.processJSONDataRecordsIntoCoreData
} else {
self.processJSONDataRecordsForDeletion
}
}];
method to take those operations created above and do something else afterwards. Iow, I would take the data written to disk and parse it with those self.processJSONDataRecords... methods.
Im not sure what would be the new equivalent?
The equivalent functionality in AFNetworking 2.0 is provided by AFURLConnectionOperation +batchOfRequestOperations:progressBlock:completionBlock:.
The difference here is that the developer is ultimately responsible for enqueuing the array of batched operations, using NSOperationQueue -addOperations:waitUntilFinished:.

How to unit test api calls using AFNetworking

I have an iOS app I'm working on, which connects to a third-party web service. I have around 50 different calls, and want to write unit tests using Kiwi, but I have no idea where to start.
As I'm not responsible for the API, I need to just check that my calls are pointing to the correct URL, using the correct GET or POST method.
Is there any way to test this properly?
Heres an example of one of my calls:
+ (void)listsForUser:(NSString *)username
response:(void (^)(NSArray *lists))completion
{
NSString *path = [NSString stringWithFormat:#"user/list.json/%#/%#", TRAKT_API_KEY, username];
[TNTraktAPIManager requestWithMethod:GET
path:path
parameters:nil
callback:^(id response) {
completion(response);
}];
}
Which calls the following helper method
+ (void)requestWithMethod:(HTTPMethod)method
path:(NSString *)path
parameters:(NSDictionary *)params
callback:(void (^)(id response))completion
{
NSString *methodString = #"POST";
if (method == GET) {
methodString = #"GET";
}
// Setup request
NSURLRequest *request = [[TraktAPIClient sharedClient] requestWithMethod:methodString
path:path
parameters:params];
// Setup operation
AFJSONRequestOperation *operation =
[AFJSONRequestOperation JSONRequestOperationWithRequest:request
success:^(NSURLRequest *request,
NSHTTPURLResponse *response,
id JSON) {
id jsonResults = JSON;
completion(jsonResults);
} failure:^(NSURLRequest *request,
NSHTTPURLResponse *response,
NSError *error,
id JSON) {
id jsonResults = JSON;
completion(jsonResults);
NSLog(#"%s: error: %#", __PRETTY_FUNCTION__, error);
}];
// TODO: Queue operations
[operation start];
}
If you set a shouldEventually expectation on the helper class and use the receive:(SEL)withArguments:(id)... form, then you can check that the argument received is what you'd expect it to be.
Two gotchas worth knowing about are setting the expectation before making the call; and using the shouldEventually form rather than should so that the test is delayed long enough for the call to be made.
I highly recommend checking out OHHTTPStubs for unit testing your API Classes.
Unit tests should be deterministic and adding internet a potentially unpredictable API into the mix makes the testing conditions non-deterministic.
OHTTPStubs will allow you to stub the response to your outgoing HTTP Requests. Basically, it intercepts your HTTP Traffic and if the request matches criteria that you set, it gives a canned response that you declare in JSON (rather than an unpredictable result from the API). This allows you to configure different response scenarios in your test classes: ie. 404 error, partial response data, etc.. to use in your tests.
Here's an example:
I created this JSON Stub and saved as a JSON file:
{
"devices" : [
{
"alarm" : {
"alarm_id" : 1,
"attack_time" : "<null>",
"defined_time" : "2014-04-14T04:21:36.000Z",
"device_id" : 7,
"is_protected" : 0
},
"device_type" : "iPhone",
"id" : 7,
"os_version" : "7.1"
}
],
"email" : "mystubemail#gmail.com",
"facebook_id" : 5551212,
"id" : 3,
"name" : "Daffy Duck"
}
Whenever I network requests are made in the API Call, this JSON is returned because of this OHHTTPStub which is declared in the test class to run before all tests.
[OHHTTPStubs stubRequestsPassingTest:^BOOL(NSURLRequest *request) {
BOOL stringFound;
if ([[request.URL description] rangeOfString:[NSString stringWithFormat:#"%#devices/register?", BASEURL]].location != NSNotFound)
{
stringFound = YES;
}
NSLog(#"%d", stringFound);
return stringFound;
} withStubResponse:^OHHTTPStubsResponse*(NSURLRequest *request) {
// Stub it with our "RegisterDevice.json" stub file
return [[OHHTTPStubsResponse responseWithFileAtPath:OHPathForFileInBundle(#"RegisterDevice.json",bundle)
statusCode:200 headers:#{#"Content-Type":#"text/json"}] requestTime:1.0 responseTime:1.0];
}];
I'm not sure if Kiwi allows for async testing, but if not I also recommend looking into Specta and the matching framework Expecta. They allow for super easy Asynchronous unit testing, which when combined with OHHTTPStubs provides all you need to unit test API Calls.

Resources