Cocoapods: Running tests fails with `xctest The bundle “$(PRODUCT_NAME)” couldn’t be loaded because its executable couldn’t be located. Try reinstalling the bundle.`

Created on 27 Oct 2017  Â·  5Comments  Â·  Source: CocoaPods/CocoaPods

Report

Running test_spec fails for some pods with error:

Test target ***-iOS-Unit-Tests encountered an error (Early unexpected exit, operation never finished bootstrapping - no restart will be attempted)

Console output:

2017-10-27 12:51:23.548078-0700 xctest[3303:5268017] The bundle “$(PRODUCT_NAME)” couldn’t be loaded because its executable couldn’t be located. Try reinstalling the bundle.

What did you do?

Create test_spec
Run pod_install
Run tests from generated schema

What did you expect to happen?

All tests to pass

What happened instead?

Running test_spec fails for some pods with error:

Test target ***-iOS-Unit-Tests encountered an error (Early unexpected exit, operation never finished bootstrapping - no restart will be attempted)

Console output:

2017-10-27 12:51:23.548078-0700 xctest[3303:5268017] The bundle “$(PRODUCT_NAME)” couldn’t be loaded because its executable couldn’t be located. Try reinstalling the bundle.

CocoaPods Environment

Same behavior for 1.3.1 and 1.4.0.beta2

Stack

   CocoaPods : 1.4.0.beta.2
        Ruby : ruby 2.2.5p319 (2016-04-26 revision 54774) [x86_64-darwin15]
    RubyGems : 2.6.13
        Host : Mac OS X 10.13 (17A405)
       Xcode : 9.0 (9A235)
         Git : git version 2.10.2
Ruby lib dir : /Users/amatosov.ctr/.rbenv/versions/2.2.5/lib
Repositories : master - https://github.com/CocoaPods/Specs.git @ 094385f668a035b1ce1c1275731ed1e58a538020

Installation Source

Executable Path: /Users/amatosov.ctr/.rbenv/versions/2.2.5/bin/pod

Plugins

claide-plugins         : 0.9.2
cocoapods-deintegrate  : 1.0.1
cocoapods-dependencies : 1.0.0.beta.1
cocoapods-packager     : 1.5.0
cocoapods-plugins      : 1.0.0
cocoapods-search       : 1.0.0
cocoapods-stats        : 1.0.0
cocoapods-trunk        : 1.3.0
cocoapods-try          : 1.1.0
cocoapods_debug        : 0.1.0

Project that demonstrates the issue

I was not able to reproduce it on test project, yet.
Once I manage to isolate the problem I will post link here.

Any ideas/suggestions/guesses are very welcome.

awaiting input

Most helpful comment

The real issue was not a CocoaPods issue.
One of test specs was picking up Info.plist from the old test target as resource. This was causing failure to start tests for whatever reason...

Also for some reason derived pods tests were also picking the same file. I think it was because of a bug with copying resources of pods into test targets even when built as frameworks. And it was copying resources from test specs as well.

All 5 comments

Please attach sample project.

The real issue was not a CocoaPods issue.
One of test specs was picking up Info.plist from the old test target as resource. This was causing failure to start tests for whatever reason...

Also for some reason derived pods tests were also picking the same file. I think it was because of a bug with copying resources of pods into test targets even when built as frameworks. And it was copying resources from test specs as well.

👍 thanks for getting back to this.

Just in case anyone else ends up here, I was also having the same issue after moving from an old test target to a new test spec.
I was still having the issue even after removing the old Info.plist, what fixed it for me was:
commenting out the pod in Podfile doing a pod install then uncommenting and pod install again.

As the mentioned answer was not sufficient enough, here are my additional insights:

Yes, there was an Info.plist file loaded, which should not have been loaded. But where did it come from?

My Tests target (in particular my UI Tests target) had an Info.plist file on their own, that was just fine, until I decided to make use of the @testable opportunity given by Xcode nowadays.
Open your file-browser of your project in Xcode:
+0 then +1
Enter in the search field at the bottom Info.plist

Now I had two referenced Info.plist-files:

  1. Info.plist with Target Membership to the Target Application (which classes are also imported via @testable)
  2. Info.plist with Target Membership was the (UI) Testing Target

Just deselect the 2nd Info.plist Target membership (or delete it, if you don't need it anymore) and should be all fine.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

marzapower picture marzapower  Â·  3Comments

intelliot picture intelliot  Â·  3Comments

pronebird picture pronebird  Â·  3Comments

Curtis-Halbrook picture Curtis-Halbrook  Â·  3Comments

tlandsmancars picture tlandsmancars  Â·  3Comments