Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

isKindOfClass doesn't match across targets when using a pod

I'm having issues unit testing code involving an isKindOfClass check. There are a lot of existing question on this topic and the answers recommend:

  • Make sure -ObjC is included as an "other linker flag". It is.
  • Make sure the .m files from the project target are not added to the test target. They aren't.
  • ...?

To make sure there weren't odd circumstances, I created a fresh project. I:

  • Created an "Empty Application" project
  • Added a PodFile referencing "TwistedOakCollapsingFutures"
  • Ran pod install
  • Opened the workspace
  • Verified -ObjC is present in both targets
  • Added a method returning [TOCFuture futureWithResult:@1] to AppDelegate.m
  • Added XCTAssert([AppDelegate.makeFuture isKindOfClass:TOCFuture.class], @"") to the example test
  • Ran the unit tests (the assert failed)

Basically I have no idea why this shouldn't work. Even more oddly, if I go counter to existing answers and include AppDelegate.m in the test target, the test starts to pass.

What is going on? Am I suppose to include the source files in the test target, or am I not supposed to?

like image 558
Craig Gidney Avatar asked Oct 31 '22 18:10

Craig Gidney


1 Answers

This answer solved it for me https://stackoverflow.com/a/27165120/2777364.

In short you should not link pod with your test target and you should create separate linking with at least one other pod for test target to force generating configuration set.

target 'MainTarget' do
    pod 'PodYouTryToTest'
end

target 'Tests' do
    pod 'AtLeastOneOtherPod'
end

Answer above is "The Right Way" of solving this. As a quick workaround I can propose a method:

Class getBundleDependentClass(Class class) { 
     return NSClassFromString(NSStringFromClass(class)); 
}
like image 86
Tomasz Bąk Avatar answered Nov 15 '22 04:11

Tomasz Bąk