Can't mock class method in Pod target about ocmock HOT 4 CLOSED

I'm not aware of any issues. Are you saying everything compiles cleanly, the test gets invoked, the calls above do not throw any exceptions and still the cacheFolder message doesn't get stubbed? That would be really odd.

from ocmock.

Ok, I've created example project to visualise this problem. Please clone this repo: https://github.com/badeleux/OCMockPodTest

My output for test method:

2014-02-14 08:27:01.406 OCMockPodTest[2820:70b] TEST STUB: /Volumes/test5M /Volumes/test5M
2014-02-14 08:27:11.008 OCMockPodTest[2820:70b] TEST STUB: /Volumes/test5M ~/Library/Application Support/iPhone Simulator/7.0.3/Applications/7E89CD46-D81B-45E0-96CA-B89C8F1B0383/tmp/Incomplete
2014-02-14 08:27:21.919 OCMockPodTest[2820:70b] TEST STUB: /Volumes/test5M /Volumes/test5M

This demo presents my problem. Stubbing mechanism works for ViewController which is in app target. Moreover stubbed method cacheFolder works in test file (OCMockPodTestTests.m:39 and 41) but no longer works in ViewController.m which is shown in line 40

from ocmock.

I suspect you have include the AFNetworking classes twice in your binary. I think both your library includes libPods.a, meaning it will have a copy of all of those classes. Your test bundle also includes libPods.a, meaning it will have another copy of all those classes. In Xcode 5, it appears that in this situation (rather than duplicate symbol errors), that two versions of each Class get added to the ObjC runtime with the same name. NSClassFromString (which OCMock uses) will only find the first one, probably, and only mock that class. Hard class references in one or the other product will refer to the version of the Class linked with that product -- so your library version will point to the Class linked into your library, whilst your test class code will refer to the one compiled into the test bundle. OCMock will only modify one or the other.

So... try removing libPods.a from the "link binary with libraries" build phase from either your library or the test bundle. They should either be provided bundled inside your library (in which case remove from the test case), or users should be expected to include them along with your library if they are using it, in which case remove libPods from your library target (and the test case, as a consumer of the library, would then need to include it).

from ocmock.

Right. Thanks!

from ocmock.