0

I'm struggling to write a unit test for an API wrapper with an interface like

- (void)publish:(id<MyCustomRequest>)aRequest completionHandler:(void (^)(id<MyCustomResponse>, NSError *)) completionBlock

which calls this method under the hood:

NSURLConnection sendAsynchronousRequest:queue:completionHandler

I don't want to use a delegate instead, as the exposed API fits much more comfortably with the sendAsynchronousRequest method (and doesn't require a separate accumulator object per-request). Further, I am using OCMockito for mocking throughout the rest of the code, which doesn't support partial mocks or mocking class methods.

Are there any other testing techniques that my be able to test this function? Is it necessary to use a delegate instead?

Cody A. Ray
  • 5,869
  • 1
  • 37
  • 31

1 Answers1

0

Use the delegate-based API. I realize it's more code, but the convenience API is clearly not adequate to meet your needs (i.e. mockable with OCMockito). Furthermore, don't worry about the "overhead" of allocating one ancillary per request. I feel quite confident that there will be dozens of objects allocated behind the scenes in the system frameworks by virtue of your calling +[NSURLConnection sendAsynchronousRequest:queue:completionHandler:]; you shouldn't be concerned. That said, a single object can be the delegate for more than one request, so you needn't necessarily have more than one.

ipmcc
  • 29,581
  • 5
  • 84
  • 147
  • Tried the delegate-based API this morning, and it works fine as long as I let it start immediately on the main queue. There's something else going on when I use a new queue (startImmediately:NO, setDelegateQueue, start). But this is for another question, I suppose. – Cody A. Ray Feb 06 '13 at 17:30
  • Not to go too "obvious" here, but are you scheduling it on a runloop with `scheduleInRunLoop:forMode:` after initting it? 'cause otherwise it'll never start, so your delegate methods will never get called. – ipmcc Feb 06 '13 at 17:55