Libraries not found when using CocoaPods with iOS logic tests

IosUnit TestingCocoapods

Ios Problem Overview


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?

Ios Solutions


Solution 1 - Ios

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.

Solution 2 - Ios

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.

Configurations Snapshot

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.

Solution 3 - Ios

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.

enter image description here

Solution 4 - Ios

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.

Solution 5 - Ios

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.

Solution 6 - Ios

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

Solution 7 - Ios

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)

Solution 8 - Ios

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.

Solution 9 - Ios

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.

Solution 10 - Ios

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.

Solution 11 - Ios

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"

enter image description here

Hope this is help to some one .

Solution 12 - Ios

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.

Solution 13 - Ios

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.

Solution 14 - Ios

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.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionMark StruzinskiView Question on Stackoverflow
Solution 1 - IosKeith SmileyView Answer on Stackoverflow
Solution 2 - IosMark StruzinskiView Answer on Stackoverflow
Solution 3 - IosMingmingView Answer on Stackoverflow
Solution 4 - IosJRVView Answer on Stackoverflow
Solution 5 - IosHai Feng KaoView Answer on Stackoverflow
Solution 6 - IosElihayView Answer on Stackoverflow
Solution 7 - IosQw4z1View Answer on Stackoverflow
Solution 8 - IosMaxwellView Answer on Stackoverflow
Solution 9 - IosMat RyerView Answer on Stackoverflow
Solution 10 - IosDarren BlackView Answer on Stackoverflow
Solution 11 - IosJaywant KhedkarView Answer on Stackoverflow
Solution 12 - IosappledevguruView Answer on Stackoverflow
Solution 13 - IosMaxim KholyavkinView Answer on Stackoverflow
Solution 14 - IosFoti DimView Answer on Stackoverflow