Исходные тесты iOS не работают в рабочей области Xcode

Question

У меня есть рабочее пространство Xcode, содержащее 2 проекта Swift, OAuth и Commons.
Каждый проект имеет цель iOS-рамки и тестовую цель. Они не зависят друг от друга.
Commons проект не имеет нет зависимостей в то время как OAuth рамки целевого импорта WebKit (import WebKit).

Теперь, если я запускать тесты в Xcode тесты OAuth работают нормально, но испытания Commons неудачно со следующей журнал ошибок Xcode:

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

Если я запустить тест из командной строки с помощью следующих команд

xcodebuild -workspace Workspace.xcworkspace -configuration Debug -destination "platform=iOS Simulator,name=iPhone 6" -scheme OAuth test 

xcodebuild -workspace Workspace.xcworkspace -configuration Debug -destination "platform=iOS Simulator,name=iPhone 6" -scheme Commons test 

Я получаю следующее сообщение об ошибке после второй команды:

The bundle “CommonsTests” couldn’t be loaded because it is damaged or missing necessary resources. Try reinstalling the bundle. 
(dlopen_preflight(~/Library/Developer/Xcode/DerivedData/Workspace-aslcnsaomwggxqcxoozzfuztgszf/Build/Products/Debug-iphonesimulator/CommonsTests.xctest/CommonsTests): Library not loaded: @rpath/libswiftWebKit.dylib 
Referenced from: ~/Library/Developer/Xcode/DerivedData/Workspace-aslcnsaomwggxqcxoozzfuztgszf/Build/Products/Debug-iphonesimulator/OAuth.framework/OAuth Reason: image not found) 

В чем может быть проблема с моей настройкой? Возникает ли проблема и для кого-то еще?

---

Обходные:

1) Если я также включить WebKit в CommonsTests связывайте все работает отлично. Но поскольку нет никакой зависимости между структурами OAuth и Commons, я не вижу причин, почему это необходимо.

2) Если я переименую проект OAuth (и цель) на что-то вроде OAuth2, все будет хорошо. Это действительно странно. Может быть либо столкновение имен, либо проблема кэширования.

Облегчает ли переименование решение проблемы для кого-либо еще?

---

Пример проекта: https://www.dropbox.com/s/dn3ywhxlc9kb6y4/SampleProject.zip?dl=0

Окружение:
Xcode 7.3 (ошибка в Xcode 7.2 тоже)
OS X 10.11.4 (ошибка происходит на OS X 10.11.3 тоже)

Answer 1

Посмотрев на проблему снова, я мог найти причину странного поведения.

Короткий ответ:
Существует частная OAuth компании Apple Framework находится в /System/Library/PrivateFrameworks/OAuth.framework/OAuth, который вызывает имя столкновение с моей собственной рамкой OAuth, потому что xctest кажется связать эти рамки.

Длинный ответ:
xctest или XCTest.framework, кажется, загрузить OAuth.framework из папки Частные рамочные.

Если один использует рабочее пространство внутри Xcode, тестовая среда использует следующие переменные окружения для dyld:

"DYLD_FRAMEWORK_PATH“ = "/Users/{USER}/Library/Developer/Xcode/DerivedData/{PROJECT}/Build/Products/Debug-iphonesimulator:/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/Library/Frameworks“;

переменных имеют следующие эффекты:

DYLD_FRAMEWORK_PATH 
       This is a colon separated list of directories that contain frameworks. The dynamic linker 
       searches these directories before it searches for the framework by its install name. It 
       allows you to test new versions of existing frameworks. (A framework is a library install name 
       that ends in the form XXX.framework/Versions/YYY/XXX or XXX.framework/XXX, where XXX and YYY 
       are any name.) 

       For each framework that a program uses, the dynamic linker looks for the framework in each 
       directory in DYLD_FRAMEWORK_PATH in turn. If it looks in all the directories and can't find 
       the framework, it searches the directories in DYLD_LIBRARY_PATH in turn. If it still can't 
       find the framework, it then searches DYLD_FALLBACK_FRAMEWORK_PATH and DYLD_FALL-BACK_LIBRARY_PATH DYLD_FALLBACK_LIBRARY_PATH 
       BACK_LIBRARY_PATH in turn. 

DYLD_FRAMEWORK_PATH определяет поиск каталоги для Frameworks и переопределяют пути поиска по умолчанию и имена установки, которые встраиваются в зависимый bi ни капли. Даже если бинарные определяет рамки пути установки, как /System/Library/Frameworks/OAuth переменная среды приводит к поведению, что каталог /Users/{USER}/Library/Developer/Xcode/DerivedData/{PROJECT}/Build/Products/Debug-iphonesimulator ищется для ​OAuth.framework/OAuth двоичного независимо от фактической установки имени.

Это поведение предназначено, поскольку оно позволяет переопределять Framework в существующем двоичном коде с более новыми версиями без необходимости перекомпилировать двоичный файл.

Однако это может также влечь за собой вводящую в заблуждение ссылку на двоичные файлы, если две структуры имеют одинаковые имена. Затем можно загрузить одну из Рамок с таким же именем, даже если другой из них указан по пути. Если каталог первого находится в DYLD_FRAMEWORK_PATH либо до другого каталога, либо вообще, то первый выбирается из-за его имени и независимо от указанного пути имени установки.

Конкретный пример:

xctest двоичная команда загрузки: ​/System/Library/PrivateFrameworks/OAuth.framework/OAuth (compatibility version 300.0.0, current version 1280.24.0)

OAuth присутствует в следующих путей:
/System/Library/PrivateFrameworks/OAuth.framework/OAuth /Users/{USER}/Library/Developer/Xcode/DerivedData/{PROJECT}/Build/Products/Debug-iphonesimulator/OAuth.framework/OAuth

xctest начинается со следующей переменной среды:
"DYLD_FRAMEWORK_PATH“ = "/Users/{USER}/Library/Developer/Xcode/DerivedData/{PROJECT}/Build/Products/Debug-iphonesimulator:/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/Library/Frameworks“;

Тогда Framework OAuth в
/Users/{USER}/Library/Developer/Xcode/DerivedData/{PROJECT}/Build/Products/Debug-iphonesimulator/OAuth.framework/OAuth
используется, даже если установить имя является
/System/Library/PrivateFrameworks/OAuth.framework/OAuth