¿Cómo me burlo de un método que acepta un identificador como argumento en OCMock?

Question

estoy tratando de burlarse de un método que tiene el equivalente a la firma siguiente:

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

quiero que vuelva un pequeño diccionario para que mi prueba puede asegurarse de que el código utiliza el diccionario correctamente. sin embargo, no importa lo que haga OCMock siempre devuelve nada del método, independientemente de cómo lo resuelvo. El error comienza como nula en el código que estoy probando, y éstas son las diferentes maneras lo he intentado stubbing que:

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]]; 

y ninguno de ellos trabajan. ¿El soporte de OCMock se maneja como argumentos de mensajes ocultos y, de ser así, cuál es la forma correcta de hacerlo?

Answer 1

Tristemente, tampoco he encontrado una buena solución para esto. Lo mejor que puedo decir es tratar de hacer que el uso del NSError ** sea lo más pequeño posible, y luego ponerlo en una función aislada que pueda burlar completamente en su simulacro parcial.

Estoy descubriendo que cualquier código que utiliza algo más que un NSObject * (o derivado) o valores primitivos (NSInteger, BOOL, etc.) es prácticamente imposible de probar con OCMock.

Answer 2

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

o

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

También podría hacer

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

pero esto podría hacer que el código para pensar incorrectamente que pasa de nuevo un verdadero NSError.

Answer 3

Con ARC, su declaración de método será probablemente el siguiente aspecto:

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

Aquí es cómo se burlan de estos tipos de métodos:

BOOL mockDoSomething = YES; 

NSError __autoreleasing *error = nil; 

[[[mock stub] andReturn:someDict] uploadValues:OCMOCK_VALUE(mockDoSomething) error:&error]; 

Answer 4

NSError *__autoreleasing *err = (NSError *__autoreleasing *) [OCMArg anyPointer]; 

[[[_mockReporter stub] andReturnValue:OCMOCK_VALUE((BOOL){YES})] 
    yourMethodCall:err]; 

Answer 5

he creado una categoría en OCMArg a ayuda con esta situación.

OCMArg + Helpers.h:

@interface OCMArg (Helpers) 

+ (NSError *__autoreleasing *)anyError; 

@end 

OCMArg + Helpers.m:

@implementation OCMArg (Helpers) 

+ (NSError *__autoreleasing *)anyError { 
    return (NSError *__autoreleasing *)[OCMArg anyPointer]; 
} 

@end 

Entonces, cada vez que tengo un parámetro de error que necesito para burlarse, utilice anyError, así:

[[myMock stub] someMethodWithArg:anArg error:[OCMArg anyError]];