Ошибка Swift Typhoon в тестовой цели - не подкласс Typhoon Assembly

Я пытаюсь настроить структуру Typhoon с помощью примера проекта, и он отлично работает, когда я запускаю симулятор, но выдает ошибку, когда я пытаюсь запустить тесты. Ошибка следующая:

NSInvalidArgumentException", причина: "Класс "DI_Example.MyAssembly" не является подклассом TyphoonAssembly"

Теперь я прочитал здесь и здесь, что это вызвано двойной компоновкой пакета Typhoon из-за CocoaPods. Итак, это мой подфайл, и не похоже, что он должен быть связан дважды

platform :ios, '8.0'

target 'DI_Example', :exclusive => true do
    pod 'Typhoon', '~> 2.3' end

target 'DI_ExampleTests', :exclusive => true do end

inhibit_all_warnings!

Кроме того, когда я меняю цель тестов с стиля приложения на стиль логики, все работает нормально (я предполагаю, что пакет не импортируется дважды). Может ли кто-нибудь определить проблему с тем, что я делаю?

Кажется, что ошибка возникает еще до того, как я попал в мой тест, поэтому я предполагаю, что это связано со связью двух целей.

Вот мой тест (который будет пройден, если я установлю для хоста Приложение значение Нет)

var controller: HomeViewController!
override func setUp() {
    super.setUp()
    let ctrlAssembly = ControllersAssembly()
    let blAssembly = BusinessLogicAssembly()
    ctrlAssembly.blAssembly = blAssembly
    let factory = TyphoonBlockComponentFactory(assemblies: [blAssembly, ctrlAssembly])
    let configurer = TyphoonConfigPostProcessor()
    configurer.useResourceWithName("Info.plist")
    factory.attachPostProcessor(configurer)


    controller = factory.componentForKey("homeViewController") as HomeViewController
}

func testControllerTitle() {
    // Arrange

    // Act
    controller.viewDidLoad()

    // Assert
    println(controller.title)
    XCTAssertTrue(controller.title == "Root View", "Title is set")
}

person Adrian Hristov    schedule 16.12.2014    source источник
comment
Вы упомянули, что зависимости Typhoon не связаны дважды. Можете ли вы проверить это, проверив вкладку «Фазы сборки» вашей тестовой цели? Вы должны увидеть библиотеку, связанную в разделе «Связать двоичный файл с библиотеками».   -  person jervine10    schedule 16.12.2014
comment
он говорит «0 элементов» для тестовой цели и «1 элемент» для цели приложения, которая является libPods.a   -  person Adrian Hristov    schedule 16.12.2014
comment
Я повторно использую один и тот же Pods-DI_Example.debug.xcconfig в конфигурации обоих целевых объектов, но если я не укажу его для тестового целевого объекта, он не найдет файлы Typhoon.   -  person Adrian Hristov    schedule 16.12.2014
comment
Хм... насколько я понимаю, в Pods-DI_ExampleTests.xcconfig должен быть Typhoon, исходя из того, как настроен ваш подфайл. Можешь открыть конфиг и посмотреть, так ли это?   -  person jervine10    schedule 16.12.2014
comment
Я точно не понимаю, что он делает, но вот это GCC_PREPROCESSOR_DEFINITIONS = $(унаследовано) COCOAPODS=1 HEADER_SEARCH_PATHS = ${PODS_ROOT}/Headers/Public ${PODS_ROOT}/Headers/Public/Typhoon OTHER_CFLAGS = $(унаследовано) -isystem $ {PODS_ROOT}/Headers/Public -isystem ${PODS_ROOT}/Headers/Public/Typhoon OTHER_LDFLAGS = -ObjC -lPods-DI_Example-Typhoon OTHER_LIBTOOLFLAGS = $(OTHER_LDFLAGS) PODS_ROOT = ${SRCROOT}/Pods   -  person Adrian Hristov    schedule 16.12.2014
comment
Итак, я заметил, что все мои классы (сборки, контроллеры и т. д.) являются членами обеих целей (которые я установил специально), но, глядя на пример Swift Typhoon, их классы не нацелены на тестовую цель. Знаете ли вы, как я могу добиться этого без выдачи ошибки о том, что классы отсутствуют?   -  person Adrian Hristov    schedule 16.12.2014
comment
Я рекомендую изменить конфигурацию тестовой цели, чтобы она указывала на Pods-DI_ExampleTests.xcconfig. Затем добавьте библиотеку libPods-DI_ExampleTests.a в цель в разделе «Связать двоичный файл с библиотеками».   -  person jervine10    schedule 16.12.2014
comment
Давайте продолжим обсуждение в чате.   -  person jervine10    schedule 16.12.2014


Ответы (1)


Так что мне удалось решить проблему. Проблема заключалась в том, что, поскольку у меня не было никаких зависимостей от целевого объекта тестирования, у меня не было Pods-PocketForecastTests.debug.xcconfig, поэтому в конфигурации моего проекта я использовал тот же файл конфигурации, что и целевое приложение, что, как я полагаю, вызывает его двойное связывание.

person Adrian Hristov    schedule 16.12.2014