I'm writing some tests, where I need to
- stub a call to a mock CLLocationManager to return a particular CLLocation
- and in turn that CLLocation needs to have a timestamp that is in the past
Creating instances of CLLocation is easy enough, but the timestamp property on it is read-only and fixed to the point in time when the instance was created. So, I planned to create a mock CLLocation, and stub the timestamp call too.
So, code looks like this:
[[CLLocationManager stubAndReturn:theValue(YES)] locationServicesEnabled];
NSDate *oldDate = [IPPOTestSupportMethods createNSDateSubtractingDays:2];
//TODO - Why is line below failing
[[expectedOldLocationMock stubAndReturn:oldDate] timestamp];
[[locationMgrMock stubAndReturn:expectedOldLocationMock] location];
In summary, I've got a CLLocationManager mock, I create an NSDate that is two days earlier than today. I want that date to be returned when I call
[cllocationmock timestamp];
However, I'm getting and ARC Semantic Issue.
IPPOLocationManagerDelegateImplKiwiTests.m:203:33: Multiple methods named 'timestamp' found with mismatched result, parameter type or attributes
Is this an issue in Kiwi, or am I missing something?
I was able to make this work by using the selector-stubbing technique instead of the message pattern technique:
I get the same error as you when using the message pattern technique (
stubAndReturn:
):If you inspect this error in the Issue Navigator, you should see that it points to two different classes that declare a
timestamp
selector: classUIAcceleration
declares…and class CLLocation declares
Note the structure of the "message pattern" stubbing technique:
The
stubAndReturn:
method returns an opaque object of typeid
. Thus, it's equivalent to this:Here, "messageToStub" is your
timestamp
selector. So you're saying to send the messagetimestamp
to an unknown object of typeid
. Since at compile time we make no assertion about the type of the object being sent the timestamp selector, it can't know which version of that timestamp property you mean, and thus it can't determine the correct return type.You can reproduce the same error by simply doing this:
The conclusion is that the message-pattern stubbing technique just won't work well when there are different declarations visible of the same selector name.