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 bu

Answer 1

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.

Answer 2

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 3

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 4

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 5

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 6

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.