Связать структуру с приложением и тестовой целью

У меня есть настраиваемая платформа, которую я использую в своем обычном целевом приложении, а также в соответствующей цели UnitTest. Оказывается, это сбивает с толку среду выполнения таким образом, что она не может выбрать правильную реализацию, поскольку у нее есть несколько вариантов:

objc[35580]: Class AClass is implemented in both ../MyApp.app/MyApp and ../MyApp.app/MyAppTests. One of the two will be used. Which one is undefined.

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

Таким образом, это сводится к следующим двум вопросам:

  1. Я не вижу похожих журналов, например. компоненты UIKit, но эта структура также связана с обеими целями. Я неправильно скомпилировал фреймворк?
  2. Это просто тривиальная проблема конфигурации, которую я пропустил?

PS: я уже проверил подобные сообщения, такие как 1 или 2, но хотя все настроено как описано, проблема остается.


xcode ios objective-c objective-c-runtime sentestingkit
person Community    schedule 01.04.2014    source источник
comment
Это связано с тем, что создаваемые вами фреймворки связаны статически, а не динамически. Если вы просто не связываетесь с фреймворком в своем пакете тестов, он должен работать, однако вам все равно понадобятся заголовки.   -  person Richard J. Ross III    schedule 02.04.2014
comment
Но что, если мне нужны некоторые объекты, которые я использую не в своем приложении, а в тестах, которые удаляются из приложения при связывании с тестами? Затем я сталкиваюсь с ошибками компоновщика, если просто включаю заголовки.   -  person    schedule 05.04.2014
comment
Ваши ошибки компоновщика, скорее всего, связаны с другой проблемой конфигурации сборки. Ричард прав. Вы должны ссылаться на свою структуру в приложении, а НЕ в модульных тестах. Исправьте проблему со связыванием фреймворка, как описано, а затем отдельно устраните другие проблемы со связыванием.   -  person quellish    schedule 09.04.2014
comment
не могли бы вы опубликовать свои пути поиска фреймворка из обеих ваших целей? возможно, проблема в том, что ссылка на фреймворк жестко запрограммирована, а не является динамической ($SRCROOT).   -  person Naor Levi    schedule 10.04.2014

Ответы (3)


arrow_upward
2
arrow_downward

Вы добавили структуру зависимостей в цель Tests. Это ошибочное мышление. Поскольку ваше основное приложение ТАКЖЕ экспортирует ту же самую структуру, вы будете получать предупреждения о повторяющихся символах для любых классов, найденных в среде.

Удалив фреймворк из целевого объекта тестирования, вы можете устранить предупреждения. Помните, что вы не теряете никакой функциональности, если не связываетесь с той же платформой в тестовом целевом объекте. Поверьте мне, ваш код все еще там.

person Sam    schedule 07.04.2014
comment
Это не так, так как я не использую нужные мне детали в тестовом мишени внутри обычного. Таким образом, я сталкиваюсь с ошибками компоновщика. - person ; 07.04.2014
comment
Вы говорите, что вам нужны части фреймворка исключительно для тестирования? В этом случае я бы создал RELEASE и TEST версию фреймворка и связал его с правильным фреймворком во время компиляции, снова обеспечив однократное связывание с вашим фреймворком. - person Sam; 07.04.2014

arrow_upward
2
arrow_downward

Я столкнулся с аналогичной проблемой здесь: Xcode5: создание новой цели тестирования

Суть в том, чтобы создать новый пакет модульного тестирования, указать его на исходную цель и больше ничего не делать! Если вы начнете включать фреймворки и исходные файлы в тестовую цель, это вызовет эти ошибки связывания. Предполагается, что тестовая цель «внедряет» тестовые классы в фактическую цель, а не создает новую отдельную цель сама по себе. Так что вам просто нужно импортировать файлы заголовков в свой тестовый класс и написать свои тестовые примеры.

person Z S    schedule 10.04.2014

arrow_upward
2
arrow_downward

Я думаю, что пакет должен только «читать» заголовочные файлы фреймворка, но не создавать исходники и оставлять эту задачу приложению (удалить файлы фреймворка .m из цели UnitTest).

Прямо сейчас App и UnitTest строят Framework, поэтому классы дублируются.

person Rivera    schedule 04.04.2014
comment
Они не строят Framework, он уже готов. В этом весь смысл использования Framework. Вместо этого оба явно связывают Framework. - person ; 04.04.2014
comment
Если вы создаете тесты приложения, продукт обязательно является зависимостью. - person CodaFi; 05.04.2014
comment
Как насчет Swift, где у нас нет файлов .h и .m? - person Raphael Oliveira; 18.05.2016