how to unit test a NSURLConnection Delegate?

Question

How can I unit test my NSURLConnection delegate? I made a ConnectionDelegate class which conforms to different protocols to serve data from the web to different ViewControllers. Before I get too far I want to start writing my unit tests. But I don't know how to test them as a unit without the internet connection. I would like also what I should do to treat the asynchronous callbacks.

Guide

Answer 1

This is similar to Jon's response, couldn't fit it into a comment, though. The first step is to make sure you are not creating a real connection. The easiest way to achieve this is to pull the creation of the connection into a factory method and then substitute the factory method in your test. With OCMock's partial mock support this could look like this.

In your real class:

- (NSURLConnection *)newAsynchronousRequest:(NSURLRequest *)request
{
    return [[NSURLConnection alloc] initWithRequest:request delegate:self];
}

In your test:

id objectUnderTest = /* create your object */
id partialMock = [OCMockObject partialMockForObject:objectUnderTest];
NSURLConnection *dummyUrlConnection = [[NSURLConnection alloc] 
    initWithRequest:[NSURLRequest requestWithURL:[NSURL URLWithString:@"file:foo"]] 
    delegate:nil startImmediately:NO];
[[[partialMock stub] andReturn:dummyUrlConnection] newAsynchronousRequest:[OCMArg any]];

Now, when your object under test tries to create the URL connection it actually gets the dummy connection created in the test. The dummy connection doesn't have to be valid, because we're not starting it and it never gets used. If your code does use the connection you could return another mock, one that mocks NSURLConnection.

The second step is to invoke the method on your object that triggers the creation of the NSURLConnection:

[objectUnderTest doRequest];

Because the object under test is not using the real connection we can now call the delegate methods from the test. For the NSURLResponse we're using another mock, the response data is created from a string that's defined somewhere else in the test:

int statusCode = 200;
id responseMock = [OCMockObject mockForClass:[NSHTTPURLResponse class]];
[[[responseMock stub] andReturnValue:OCMOCK_VALUE(statusCode)] statusCode];
[objectUnderTest connection:dummyUrlConnection didReceiveResponse:responseMock];

NSData *responseData = [RESPONSE_TEXT dataUsingEncoding:NSASCIIStringEncoding];
[objectUnderTest connection:dummyUrlConnection didReceiveData:responseData];

[objectUnderTest connectionDidFinishLoading:dummyUrlConnection];

That's it. You've effectively faked all the interactions the object under test has with the connection, and now you can check whether it is in the state it should be in.

If you want to see some "real" code, have a look at the tests for a class from the CCMenu project that uses NSURLConnections. This is a little bit confusing because the class that's tested is named connection, too.

http://ccmenu.svn.sourceforge.net/viewvc/ccmenu/trunk/CCMenuTests/Classes/CCMConnectionTest.m?revision=129&view=markup

Heroism

This is very useful. I'm trying to extend it to cover a back and forth conversation rather than a one off request/response scenario, but I'm not having much luck. I posted a separate question: #16473378 – Explore

Answer 2

EDIT (2-18-2014): I just stumbled across this article with a more elegant solution.

http://www.infinite-loop.dk/blog/2011/04/unittesting-asynchronous-network-access/

Essentially, you have the following method:

- (BOOL)waitForCompletion:(NSTimeInterval)timeoutSecs {
    NSDate *timeoutDate = [NSDate dateWithTimeIntervalSinceNow:timeoutSecs];

    do {
        [[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:timeoutDate];
        if([timeoutDate timeIntervalSinceNow] < 0.0)
            break;
    } while (!done);

    return done;
}

At the end of your test method, you make sure things haven't timed out:

STAssertTrue([self waitForCompletion:5.0], @"Timeout");

Basic format:

- (void)testAsync
{
    // 1. Call method which executes something asynchronously 
    [obj doAsyncOnSuccess:^(id result) {
        STAssertNotNil(result);
        done = YES;
    }
    onError:^(NSError *error) [
        STFail();
        done = YES;
    }

    // 2. Determine timeout
    STAssertTrue([self waitForCompletion:5.0], @"Timeout");
}    

==============

I'm late to the party, but I came across a very simple solution. (Many thanks to http://www.cocoabuilder.com/archive/xcode/247124-asynchronous-unit-testing.html)

.h file:

@property (nonatomic) BOOL isDone;

.m file:

- (void)testAsynchronousMethod
{
    // 1. call method which executes something asynchronously.

    // 2. let the run loop do its thing and wait until self.isDone == YES
    self.isDone = NO;
    NSDate *untilDate;
    while (!self.isDone)
    {
        untilDate = [NSDate dateWithTimeIntervalSinceNow:1.0]
        [[NSRunLoop currentRunLoop] runUntilDate:untilDate];
        NSLog(@"Polling...");
    }

    // 3. test what you want to test
}

isDone is set to YES in the thread that the asynchronous method is executing.

So in this case, I created and started the NSURLConnection at step 1 and made the delegate of it this test class. In

- (void)connection:(NSURLConnection *)connection didReceiveResponse:(NSURLResponse *)response

I set self.isDone = YES;. We break out of the while loop and the test is executed. Done.

Aha

Answer 3

I avoid networking in unit tests. Instead:

• I isolate NSURLConnection within a method.
• I create a testing subclass, overriding that method to remove all traces of NSURLConnection.
• I write one test to ensure that the method in question will get invoked when I want. Then I know it'll fire off an NSURLConnection in real life.

Then I concentrate on the more interesting part: Synthesize mock NSURLResponses with various characteristics, and pass them to the NSURLConnectionDelegate methods.

Pantagruel

What about mocking or stubbing the NSURLConnection in my delegate methods? I subclassed NSURLConnection to contain the NSData received, the receiver (a JSON fetcher I will be writing), and the request used to invoke it. – Guide

After looking at my code and reading your answer again, I see that I'm on the right track! – Guide

My NSURLConnection is already isolated in a method -(void)sendRequest:(NSURLRequest *) request forReceiver:(id <JSONDelegate>) receiver. I can test all my other methods to ensure the URLs and the requests are well-formated. On the other side, by overriding the sendRequest method I can pass fake data to test my receiver. Does this make sense? – Guide

Answer 4

My favorite way of doing this is to subclass NSURLProtocol and have it respond to all http requests - or other protocols for that matter. You then register the test protocol in your -setup method and unregisters it in your -tearDown method. You can then have this test protocol serve some well known data back to your code so you can validate it in your unit tests.

I have written a few blog articles about this subject. The most relevant for your problem would probably be Using NSURLProtocol for Injecting Test Data and Unit Testing Asynchronous Network Access.

You may also want to take a look my ILCannedURLProtocol which is described in the previous articles. The source is available at Github.

Karinekariotta

I read both articles and they are really interesting. I actually started getting ideas on how to tackle this problem thanks to them. I don't think I will need to subclass NSURLProtocol (and I prefer not to do it in case it changes in the future) because my connection delegate doesn't process the data. I'm using my receiver as an observer. so by overriding the method that starts the connection I can serve the data I want. PS: great blog! I have bookmarked IL ;) – Guide

Thanks for you comments. Just to clarify, the ILCannedURLProtocol is not intended to find its way into production code, so I wouldn't worry too much about changes to the underlying NSURLProtocol. If that should happen it is merely a change to your test setup. – Karinekariotta

MockNSURLConnection works amazingly well with your approach. – Bargain

Answer 5

you might want to give this a chance:

https://github.com/marianoabdala/ZRYAsyncTestCase

Here's some sample code of a NSURLConnection being unit tested: https://github.com/marianoabdala/ZRYAsyncTestCase/blob/12a84c7f1af1a861f76c7825aef6d9d6c53fd1ca/SampleProject/SampleProjectTests/SampleProjectTests.m#L33-L56

Chili

Try describing what content the link contains within your post. – Valuate

Answer 6

Here's what I do:

1. Get XAMPP Control Panel http://www.apachefriends.org/en/xampp.html
2. Start the apache server
3. In your ~/Sites folder, put a test file (whatever data you want, we'll call it my file.test).
4. Start your delegate using the URL http://localhost/~username/myfile.test
5. Stop the apache server when not using it.

Erick

That limit the responses to 404, 200 and no response. What if you want to test, conflicts 409, 204, 403, and the rest of the status codes, etags, compression, etc... Also, if you use an automated build server, are you going to install apache and this kind of things for every testing machine? – Retrocede

Not a method that should really be passed on as a recommendation. Guillermo covers a few of the reasons why pretty well in his comment. I think we should be encouraging better programming practices than this in answers to fellow developers... – Camara