Libraries not found when using CocoaPods with iOS logic tests

Question

I am trying to write some iOS logic tests against classes in my project that use functionality from some of the libraries in my podspec. I am using the standard unit test bundle provided in Xcode (although not Application Tests, just Unit Tests).

For example, I use Magical Record, and I have that library linked in my podspec. It is present in the Pods project in my workspace, and works as expected when the app is running in the simulator or on the device. When I try to link to the test the object that uses Magical Record, however, I get a linker error stating that it can't find the selectors from Magical Record. I have tried updating my HEADER_SEARCH_PATH in my logic testing bundle, even hard coding it to the headers directory created by CocoaPods, but no luck.

I can run unit tests against classes that do not use CocoaPods libraries with no problem.

Am I going about this wrong? Should I be doing something else to get the compiler to see the CocoaPods libraries?

Answer 1

I had issues using OpenCV under XCTest. It was giving me linker errors of Undefined symbols for architecture arm64 for classes like cv::Mat. I am installing OpenCV through CocoaPods using pod 'OpenCV', '~> 2.0' under the main target. No matter how hard I tried to put the OpenCV dependency under the test target or use inherit! :search_paths none of it worked. The solution was to create an abstract_target like so:

# Uncomment the next line to define a global platform for your project
platform :ios, '6.1.6'

abstract_target 'Shows' do
  pod 'RMVision', path: '../..'
  pod 'RMShared', path: '../../../RMShared'
  pod 'OpenCV', '~> 2.0'

  target 'RMVisionSample' do
    # Uncomment the next line if you're using Swift or would like to use dynamic frameworks
    # use_frameworks!

    # Pods for RMVisionSample
  end

  target 'RMVisionSampleTests' do
    # inherit! :search_paths
    # Pods for testing
  end

  target 'RMVisionBenchmarks' do
    # inherit! :search_paths
    # Pods for testing
  end

end 

Also useful are the pod deintegrate & pod clean commands which help to cleanup the project and make sure that you start fresh when testing. You can install those two using [sudo] gem install cocoapods-deintegrate cocoapods-clean.

Answer 2

Try This it's working for me ,

We need to set Pods in Configurations ,

The Project->Info->Configurations in the Xcode project (your project) should be set to main project 'Pods' for Debug, Release (and what else you have). See "Headers not found – search paths not included"

Hope this is help to some one .

Answer 3

CocoaPods 1.0 has changed the syntax for this. It now looks like this:

def shared_pods
    pod 'SSKeychain', '~> 0.1.4'
    ...
end

target 'Sail' do
    shared_pods
end

target 'Sail-iOS' do
    shared_pods
end

---

Pre CocoaPods 1.0 answer

What you want to use is link_with from your Podfile. Something like:

link_with 'MainTarget', 'MainTargetTests'

Then run pod install again.

Answer 4

Next syntax gives best result for me (tested under cocoapod v.1.2.1):

https://github.com/CocoaPods/CocoaPods/issues/4626#issuecomment-210402349

 target 'App' do
    pod 'GoogleAnalytics' , '~> 3.0'
    pod 'GoogleTagManager' , '~> 3.0'

     pod 'SDWebImage', '~>3.7'
     platform :ios, '8.0'
     use_frameworks!

     target 'App Unit Tests' do
         inherit! :search_paths
     end
 end

Without this I have warnings while test run about duplicate symbols.

After this warnings were disappear.

Answer 5

As of CocoaPods 1.x, there's a new way to declare shared dependencies between a target and the corresponding test target. I'd been using the accepted solution by Mark Struzinski to this point, but using this method yielded a massive number of warnings when running my tests that:

Class SomeClass is implemented in both /Path/To/Test/Target and /Path/To/App/Target. One of the two will be used. Which one is undefined.

With CocoaPods 1.x we can declare our -Test target as inheriting via the parent target's search paths, like so:

target 'MyApp' do
    pod 'aPod'
    pod 'anotherPod'
    project 'MyApp.xcodeproj'
end
target 'MyAppTests' do
    inherit! :search_paths
    project 'MyApp.xcodeproj'
end

This will result in the -Test target having access to the dependencies of the app target, without multiple binary copies. This has seriously sped up test build times for me.

Answer 6

I am working with GoogleMaps Objective-C POD integration on iOS with my Swift app and so for me the issue was that the Test target didn't have a reference to the Bridge Header File (SWIFT_OBJC_BRIDGING_HEADER) in the Build Settings. Make sure both your app and test app targets point to that so that the 3rd party API calls (maps API, etc.,) can be used in swift unit tests.

Answer 7

You can use link_with according to @Keith Smiley solution.

In case you have common pods, and specifics for each target, you might want to use the "def" option to define group of pods. and use the "def" later in exclusive target.

def import_pods
    pod 'SSKeychain'
end

target 'MyProjectTests', :exclusive => true do
  import_pods
end

target 'MyProject', :exclusive => true do
  import_pods
  pod 'Typhoon'
end

in the example above, I added 'SSKeychain' to the both targets, and 'Typhoon' only to 'MyProject' target

Answer 8

I added :exclusive => true to avoid duplicated symbol errors in the application test target.

target 'myProjectTests', :exclusive => true do
   pod 'OCMock', :head
   pod 'XCTAsyncTestCase', :git => 'https://github.com/iheartradio/xctest-additions.git'
end

link_with 'myProject', 'myProjectTests'

When I changed the application test target to the logic unit test one, the linker error occurs. After I remove :exclusive => true, everything works again.

target 'myProjectTests', do
   pod 'OCMock', :head
   pod 'XCTAsyncTestCase', :git => 'https://github.com/iheartradio/xctest-additions.git'
end

link_with 'myProject', 'myProjectTests'

:exclusive => true states that everything outside do...end should NOT be linked to myProjectTests, which is reasonable in application test targets, but it will cause linker errors in logic test targets.

Answer 9

I agree with the other answers telling that it is necessary to get the libraries linked to the test targets. However none of the suggestions so far helped me. As @fabb writes in a comment: "when testing, isSubclassOfClass: calls return NO where they should return YES. The only reason I can explain this is that the dependencies really get linked to both the main and the test target, and when the test target's bundle loader loads the main bundle, it cannot decide which class to take." I get the same problem with all the previous suggestions in this thread.

The solution that I got to work was to update my Podfile to define specific Pods for my main target and my test target:

target 'MyTarget' do
   pod 'AFNetworking', '~> 2.5.0'
   pod 'Mantle', '~> 1.5'
end

target 'MyTargetTests' do
   pod 'OCMockito', '~> 1.3.1'
end

It was necessary to specify a Pod for my test target even though I did not use any test specific Pods. Otherwise CocoaPods would not insert the necessary linking logic in my project.

This link is what helped me come to this conclusion.

Answer 10

My solution to this problem was to change my Podfile to include the library in both targets like this

target "MyApp" do  
    pod 'GRMustache', '~> 7.0.2'
end

target "MyAppTests" do
    pod 'GRMustache', '~> 7.0.2'
end

And since I'm using swift I also had to configure the test target to include the MyApp-Bridging-Header.h file. (In the Swift Compiler group under the Build Settings tab)

Answer 11

I had a similar occurrence when I lost some library files during some version control. I still saw the library file in my Pods but with the actual code missing, XCode said it was gone. To my dismay, running 'pod install' wasn't immediately bringing the lost files back.

I had to remove and replace the pod manually by doing the following:

1. Remove the library from the Podfile
2. Run 'pod install' to remove the library completely
3. Put the library back into the Podfile
4. Run 'pod install' again

This should put the library in question back in it's original form.

Answer 12

There is a solution I found here Unit Tests With CocoaPods:

Open the project file in Xcode, then choose the Project (not the target), in the right panel, there is a section called Configurations. Choose Pods in the "Based on Configuration file" column for your test target.

Answer 13

It's also worth noting that if you have libPods.a added twice, you'll get some nasty error like this:

232 duplicate symbols for architecture i386

To fix it, just delete one of the libPods.a references in your Project Explorer.

Answer 14

I figured this one out by looking at how the main target of my app was receiving settings from the CocoaPods library. CocoaPods includes an .xcconfig file named Pods.xcconfig. This file contains all of the header search paths.

If you look at your project in the project navigator and click the Info tab, you will see your build configurations listed on the top section. If you open the disclosure triangle for your different configurations, you will see Pods listed under your main target. I had to click the drop down and add Pods to the logic test target as well.

I also had to copy the settings of $(inherited) and ${PODS_HEADERS_SEARCH_PATHS} from my main target and copy them over to the logic test target under Build Settings/HEADER_SEARCH_PATHS.

Finally, I had to add libPods.a in the Link Binary with Libraries build phase for my logic tests target.

Hope this is able to help someone else.