Cocoapods: Modules not found in test targets

[Brett-Best]

🌈

• [ ] I've read and understood the *CONTRIBUTING guidelines and have done my best effort to follow.

Report

I am having trouble with "No such module 'MODULE_NAME'" errors.

Example Project

What did you do?

1) Created a new Xcode project
2) Created Podfile using template generated by running pod init
3) Added the pod Alamofire to the target "Demo App"
4) Added the pod OHHTTPStubs to the targets "Demo AppTests" and "Demo AppUITests"
5) Ran pod install --verbose
6) Opened workspace up in Xcode
7) Opened Demo_AppTests.swift and added the following to the top of the file:

import XCTest
import Alamofire
import OHHTTPStubs
@testable import Demo_App

8) Tried to use either of the libraries imported (Alamofire or OHHTTPStubs) and autocomplete wouldn't come up.
Error on import Alamofire was "No such module 'Alamofire'".
Error on import OHHTTPStubs was "No such module 'OHHTTPStubs'".

NOTE: Adding pod 'Alamofire' to the testing targets also results in the same behaviour.

These errors would sometimes disappear for around ~5 secs or until a key was pressed to make a change to the swift file if I build the targets generated by CocoaPods or ran both CMD + SHIFT + U and CMD + SHIFT + R.

Sometimes running CMD + U would let the test target compile and other times it would not.
I have also tried clearing derived data.

What did you expected to happen?

I expected that the pod Alamofire would be available for use in all targets.
I expected that the pod OHHTTPStubs would be available for use in all test targets.

What happened instead?

In the test targets the modules Alamofire and OHHTTPStubs could not be found.

That is:

Pod Alamofire is missing from the targets "Demo AppTests" and "Demo AppUITests".
Pod OHHTTPStubs is missing from the targets "Demo AppTests" and "Demo AppUITests".

Pod Env

Stack

   CocoaPods : 1.0.0.beta.4
        Ruby : ruby 2.3.0p0 (2015-12-25 revision 53290) [x86_64-darwin15]
    RubyGems : 2.5.1
        Host : Mac OS X 10.11.3 (15D21)
       Xcode : 7.2.1 (7C1002)
         Git : git version 2.5.4 (Apple Git-61)
Ruby lib dir : /Users/brettbest/.rubies/ruby-2.3.0/lib
Repositories : master - https://github.com/CocoaPods/Specs.git @ e77d73db1bdaebf03fee6dab82aae3a90c99d367

Installation Source

Executable Path: /Users/brettbest/.gem/ruby/2.3.0/bin/pod

Plugins

cocoapods-deintegrate : 1.0.0.beta.1
cocoapods-plugins     : 1.0.0.beta.1
cocoapods-search      : 1.0.0.beta.1
cocoapods-stats       : 1.0.0.beta.3
cocoapods-trunk       : 1.0.0.beta.2
cocoapods-try         : 1.0.0.beta.2

Podfile

platform :ios, '9.0'
use_frameworks!
inhibit_all_warnings!

target 'Demo App' do
  pod 'Alamofire'
end

target 'Demo AppTests' do
  pod 'OHHTTPStubs'
end

target 'Demo AppUITests' do
  pod 'OHHTTPStubs'
end

[orta]

Thanks for the great ticket! So, pods would be passed to a target by inheritance here, but you're not inheriting them. To quote the guide

platform :ios, '9.0'
inhibit_all_warnings!

target 'MyApp' do
  pod 'GoogleAnalytics', '~> 3.1'

  # Has it's own copy of OCMock
  # and has access to GoogleAnalytics via the app
  # that hosts the test target

  target 'MyAppTests' do
    inherit! :search_paths
    pod 'OCMock', '~> 2.0.1'
  end
end

So in this case you want to do something like:

target 'Demo App' do
  pod 'Alamofire'

  target 'Demo AppTests' do
    inherit! :search_paths
    pod 'OHHTTPStubs'
  end

  target 'Demo AppUITests' do
    inherit! :search_paths
    pod 'OHHTTPStubs'
  end  
end

Though I bet you could improve that even further, I think, this is guesswork now though:

target 'Demo App'
pod 'Alamofire'

abstract_target 'tests' do
  target 'Demo AppTests'
  target 'Demo AppUITests'

  inherit! :search_paths
  pod 'OHHTTPStubs'
end

[Brett-Best]

Hi @orta,

I had a look at the guide you linked to and the migration guide from 0.x to 1.0 as well as the more specific Podfile documentation whilst trying to fix this issue.

platform :ios, '9.0'
use_frameworks!
inhibit_all_warnings!

target 'Demo App' do
  pod 'Alamofire'

  target 'Demo AppTests' do
    inherit! :search_paths
    pod 'OHHTTPStubs'
  end

  target 'Demo AppUITests' do
    inherit! :search_paths
    pod 'OHHTTPStubs'
  end
end

I updated my Podfile to the above and ran pod deintegrate and pod install --verbose.
I get the same results.
I also tried that using Cocoapods 1.0.0.beta.3 because of #4943 and that didn't fix the issue either.

Thanks.

[segiddins]

Running pod deintegrate, changing the Podfile to

platform :ios, '9.0'
use_frameworks!

target 'Demo App' do
  pod 'Alamofire'

  abstract_target 'tests' do
    platform :ios, '9.0'
    target 'Demo AppTests'
    target 'Demo AppUITests'

    inherit! :search_paths
    pod 'OHHTTPStubs'
  end
end

and using https://github.com/CocoaPods/Core/pull/308 together fix the issue

[Brett-Best]

Hi @segiddins,

That doesn't seem to fix the issue I am having.

The steps I took to try and use the CocoaPods/Core#308 changes are:

1) bundle init
2) Updated Gemfile to this:

# A sample Gemfile
source "https://rubygems.org"

gem "cocoapods", :git => 'https://github.com/Brett-Best/CocoaPods.git', :ref => '4f027537d8cb8ad7272638efedbae28952522bfa'
gem 'cocoapods-core', :git => 'https://github.com/CocoaPods/Core.git', :ref => 'c16fe1529373da6268e12d2b94c0e016c7678780'

3) bundle install
4) bundle exec pod deintegrate
5) Closed Xcode and deleted derived data.
6) Updated Podfile to the one above.
7) bundle exec pod install --verbose
8) Opened the project up in Xcode, let it index.
9) Tried to compile and received the same errors as in the original report.

I have pushed the changes that it made to the Github repo linked above.

Perhaps it isn't using the changes you made in CocoaPods/Core#308.
I am pretty sure it is though. I originally just had gem 'cocoapods-core', :git => 'https://github.com/CocoaPods/Core.git', :ref => 'c16fe1529373da6268e12d2b94c0e016c7678780' in my Gemfile but then added the fork of Cocoapods I made and updated it's Gemfile to also include that line.

Also tried this Gemfile:

gem 'cocoapods', '1.0.0.beta.4'
gem 'cocoapods-core', :git => 'https://github.com/CocoaPods/Core', :branch => 'seg-grandchild-inheritance'

[Brett-Best]

@segiddins perhaps related to #4950?

[mgrebenets]

Here's a demo project I patched up together. It demonstrates the problem with test target. Hope it will be helpful with fixing the issue: https://github.com/mgrebenets/cocoapods-tests-with-transient-binary. I used 1.0.0.beta5.

Duplicating same pod for test targets is not a solution for me, because it will cause all kinds of debug log output while running the tests and on my main project it actually causes unit tests to hang and timeout.

[Brett-Best]

@mgrebenets this is also reproducible in 1.0.0.beta6.

[littlepotatosoftware]

Agree -- I'm having a similar problem using 1.0.0.beta6 and XCode 7.3. I am able to get my pods added to my regular testing target, but no "Embed Pods Frameworks" build phase is added to my UI test target, and so it is unable to run. It is easier to see this error when running xcodebuild -- it at least lets you know that it is unable to load a 3rd party library normally part of my pods. If I try to run UI tests from within XCode, I just get more vague errors, and see that the simulator is essentially killed before it even gets started. This was sort of working in XCode 7.2 - I could run the tests from within XCode, although xcodebuild hung. But, it 7.3, nothing I do with cocoapods and UI test targets seems to work.

[hijamoya]

Face the same problem described by @mgrebenets!

[neonichu]

This issue has been inactive for some time and will be closed because we want to move forward with a clean slate after our 1.0 release. If you believe this is still relevant, please retest with the 1.0 release candidate and comment with a reproducible project in order for this to become actionable again. Thanks!

[edwardvalentini]

I know this issue has been closed but I just experienced this issue with Cocoapods 1.0.0 and the way i solved it is as follows... When I tried the new cocoapods 1.0.0 syntax for the Podfile like so:

target 'Chat_Example' do
    pod 'ChatKit', :path => '../'
    target 'Chat_Example_Tests' do
         inherit! :search_paths
    end
end

then my test target was not able to import the ChatKit module. However if I write the Podfile as so
then the tests are able to import the module:

def reusepods
    pod 'ChatKit', :path => '../'
end

target 'Chat_Example' do
     reusepods
end

target 'Chat_Example_Tests' do
    reusepods
end

[rephiscorth]

I believe this thread got off-topic. The initial issue is not the inheritance, but the fact that adding a pod to a test target doesn't work, as xCode says No Such Module 'Quick'. Is there any official fix for this? or maybe an official extra step that we need to do, that is not documented?

[ferranpujolcamins]

Hello! I've followed the conversation of this topic and tried the solutions proposed here.

I couldn't make my test target use a framework without failing either because
A) "No Such Module"
or
B) throwing lots of warnings about "Class X is implemented in both..."

I still don't really know what is the correct way to write the Podfile that should let my test targets use a framework that my app is also using.
Is this still la bug? Is there a workaround that solves A) and B)?

Please excuse me if this is already explained somewhere, I've been surfing the net for long and still didn't find the answer.

Best regards, Ferran.

[Brett-Best]

Hi @ferranpujolcamins,

I still have some issues with this but my demo project demonstrating the issue started working. I did however notice this bug reported recently #5512, it seems like it might solve this issue here. If it doesn't I will try and make another demo project with the issue. If you have a demo project feel free to post it.

Thanks.

[plu]

You can try and see if the changes made in https://github.com/CocoaPods/CocoaPods/pull/5514 fixes it for your case as well.

[bobrosoft]

See the same, commented there https://github.com/CocoaPods/CocoaPods/issues/5110#issuecomment-226151163

[ferranpujolcamins]

Sorry I can't build cocoapods as described here https://guides.cocoapods.org/contributing/dev-environment.html

It keeps me warning https://github.com/CocoaPods/Xcodeproj.git (at master@1b15f4c) is not yet checked out. Run bundle install first.

[Brett-Best]

@plu I was unable to use bundler to get your branch I tried this:
gem "cocoapods", :github => "plu/CocoaPods", :branch => "inherit_framework_search_path"
But was getting this error:

Fetching https://github.com/plu/CocoaPods.git
fatal: Could not parse object '868991facb82b9c1a692b4195fc5bd6ca6a3c1ef'.
Git error: command `git reset --hard 868991facb82b9c1a692b4195fc5bd6ca6a3c1ef` in directory /Users/brettbest/.bundler/ruby/2.0.0/CocoaPods-868991facb82 has failed.
If this error persists you could try removing the cache directory '/Users/brettbest/.bundler/cache/git/CocoaPods-b847fc5be38ef41bafd24b7cca2f5339c7184af7'

I tried the suggestion but that didn't fix the issue when I ran bundle install.

[kakubei]

For me the fix was to add the HEADER_SEARCH_PATHS from Pods-project.debug.xcconfig into Pods-project-tests.debug.xcconfig. Of course, these get overwritten when you run pod install so I added a post_install lambda to the Podfile:

post_install do |installer|
    directory = installer.config.project_pods_root + 'Target Support Files/'
    podDirectory = '<directory_name>'
    fileName = podDirectory + '.debug.xcconfig'
    configFile = directory + podDirectory + fileName

    xcconfig = File.read(configFile)
    newXcconfig = 'HEADER_SEARCH_PATHS = $(inherited) ${PODS_ROOT}/Firebase/Core/Sources $(inherited) "${PODS_ROOT}/Headers/Public" "${PODS_ROOT}/Headers/Public/Carnival" "${PODS_ROOT}/Headers/Public/Crashlytics" "${PODS_ROOT}/Headers/Public/Fabric" "${PODS_ROOT}/Headers/Public/Firebase" "${PODS_ROOT}/Headers/Public/FirebaseAnalytics" "${PODS_ROOT}/Headers/Public/FirebaseCore" "${PODS_ROOT}/Headers/Public/FirebaseInstanceID" "${PODS_ROOT}/Headers/Public/FirebaseRemoteConfig" "${PODS_ROOT}/Headers/Public/Olapic-SDK-iOS" "${PODS_ROOT}/Headers/Public/Reveal-SDK" "${PODS_ROOT}/Headers/Public/SwiftGen"'
    File.open(configFile, "a") { |file| file << newXcconfig }
end

[Ankish]

This can work, Not sure if this is an ideal solution for all environments

Go to your target Build Settings -> Other linker flags -> double click . Add $(inherited) to a new line.

If you have problem with "...target overrides the GCC_PREPROCESSOR_DEFINITIONS build setting defined in..." then you must add $(inherited) to your target Build Settings -> Preprocessor Macros

[kakubei]

Adding $inherited never worked for me. I tried it numerous times.

[Ankish]

I am facing issue on pod version 1.2.1 - xcode Version 8.3.1 (8E1000a) . Any quick fixes ?

[Ankish]

Hey I just tried $(inherited) and did pod install it worked for me. Not sure of your config.
Under Schemes make sure there is a target scheme for tests too.

[reshadf]

This still occurs for me in Xcode 9.3 cocoapods 1.3.1 any fixes yet?

[gregcotten]

Yikes! This is still a problem!

[dulimarta]

I was able to find a workaround for the following runtime environment:

XCode: 9.2 (9C40b)
Cocoapods: 1.5.3

I first notice that the "Framework Search Paths" (under Build Settings) expands to "build/Debug-iphoneos/AlamoFire" "build/Debug-iphoneos/OHHTTPStubs" which is actually generated from the $(inherited) flag of FRAMEWORK_SEARCH_PATHS in XXXXXX.xcodeproj/project.pbxproj. But the actual directory name is Build/Products/Debug-iphonesimulator/zzzzzz.

To fix this issue I hand edited project.pbxproj and set the variable FRAMEWORK_SEARCH_PATHS to the following:

FRAMEWORK_SEARCH_PATHS = (
    "$(inherited)",
    "$(PROJECT_DIR)/Build/Products/Debug-iphonesimulator"
)

After rebuilding the workspace by calling pod install, XCode seemed to stop complaining "No such module"

[AshleyDeng]

@dulimarta is definitely on the right track. But I still suffer from the same problem as I use a multi-project within single workspace - Core, App1, App2, Pods and a workspace

From what I observed, the problem seemed to be the test targets DO NOT have a path to built pods frameworks from the workspace in /DerivedData. For example when built for test:

• The pod frameworks are built under WorkspaceName-HASH directory in DerivedData
• However, the Core project's BUILD_DIR is pointing to CoreName-HASH, which doesn't have any pod frameworks

I think if Core project's BUILD_DIR can point to WorkspaceName-HASH then No such module problem will go away. But I didn't come up with a reliable way for it since the hash is changed every time clean and build.

Workaround
Build Pods from scheme list manually. Steps are:

• Click Manage Schemes from scheme list
• Enable pods that are used in your test targets, example, Nimble, Quick, OHHTTPStubs
• Select those pods from scheme list and build them one by one
• Select your project scheme and run tests - errors are gone and we can use auto-complete for pods

[GalCohen]

@AshleyDeng I got quite a long list of schemes, have you found a solution since that doesn't require all this manual work 😅 i've got the same issue.

[MrMatten]

I have just run into this problem and unable to make it work with the suggestions..