views:

122

answers:

2

I'm trying to mock a method that has the equivalent of the following signature:

- (NSDictionary *) uploadValues:(BOOL)doSomething error:(NSError **)error

I want it to return a small dictionary so that my test can make sure the code uses the dictionary properly. however, no matter what i do OCMock always returns nil from the method, regardless of how i stub it out. The error begins as nil in the code i'm testing, and these are the different ways i've tried stubbing it:

NSError * error = nil;
[[[mock stub] andReturn:someDict] uploadValues:YES error:&error];

[[[mock stub] andReturn:someDict] uploadValues:YES error:nil];

[[[mock stub] andReturn:someDict] uploadValues:YES error:[OCMArg any]];

and none of them work. Does OCMock support handles as stubbed message arguments and if so, what's the correct way to do it?

+1  A: 

Sadly, I haven't found a good solution for this either. The best I can say is to try to make the use of the NSError** as small as possible, and then put it in an isolated function that you can completely mock out on your partial mock.

I'm finding that any code that uses anything other than an NSObject* (or derived) or primitive values (NSInteger, BOOL, etc) is pretty much impossible to test using OCMock.

Chris Phillips
Yeah, that makes sense. Thanks for the insight.
Kevlar
A: 
[[[mock stub] andReturn:someDict] uploadValues:YES error:[OCMArg setTo:nil]];

or

NSError* someError = ...
[[[mock stub] andReturn:someDict] uploadValues:YES error:[OCMArg setTo:someError]];

You could also do

[[[mock stub] andReturn:someDict] uploadValues:YES error:[OCMArg anyPointer]];

but this might cause your code to incorrectly think that you passed back a real NSError.

Andreas Järliden