0

Consider the following code 

OCMockObject *mock = [OCMockObject mockForClass:[NSObject class]];
[[[mock expect] andReturnValue:OCMOCK_VALUE((BOOL){YES})] isEqual:[OCMArg any]];
[mock isEqual:[NSObject new]];
[mock verify];

Can someone, please, tell me why this fails with

test failure: -[NSObject_tests testIsEqualIsCalled] failed: OCMockObject[NSObject]: expected method was not invoked: (null)

This makes literally no sense. I tried using andReturn: instead of andReturnValue: and still nothing.

L_Sonic
  • 594
  • 6
  • 22

1 Answers1

1

expect returns an instance of OCMockRecorder. OCMock works by intercepting methods that OCMockRecorder does not implement. So you can't really mock methods defined by NSProxy, NSObject, or OCMockRecorder. You'll get the same results with this test:

-(void)testSomething {
    id mock = [OCMockObject mockForClass:[NSObject class]];
    [[[mock expect] andReturn:OCMOCK_VALUE((int){2})] hash];
    [mock hash];
    [mock verify];
}

If this is more than an academic exercise and you want to actually test a custom isEqual: implementation, there should be no reason to mock it. Just call isEqual: directly with objects that should and shouldn't match in your test.

Christopher Pickslay
  • 17,523
  • 6
  • 79
  • 92
  • Hey, I noticed and I changed my tests but What about custom overrides of isEqual: and hash? – L_Sonic Mar 13 '14 at 11:43
  • 1
    Overrides of any NSObject protocol methods are going to be very difficult to mock out (unless you have a custom subclass of OCMockClassObject which handles it explicitly). Usually those methods are only overridden on value-type objects (i.e. there is never expected to be *any* context where different instances need to be distinguished from each other), and it's almost always easier to test those directly rather than using mocks. You should be able to just allocate those objects and call the methods. – Carl Lindberg Mar 13 '14 at 15:20
  • @L_Sonic what about custom overrides of isEqual: and hash? If you want to test the behavior of your override, why would you mock it? – Christopher Pickslay Mar 13 '14 at 18:37
  • You are right. I realized that when I started testing for the wrong stuff. It came to that fine line of testing the interface (what the method is suppose to do) and the implementation (the contents of the method). Coding for 10-12 hours can mush up your brain :D – L_Sonic Mar 14 '14 at 12:17