OCUnit тестирует встроенный фреймворк - PullRequest
5 голосов
/ 19 мая 2010

ОБНОВЛЕНИЕ: я закончил тем, что сдался и добавил GHUnit к своему проекту вместо этого. Я начал работать с GHUnit за считанные минуты.

ОБНОВЛЕНИЕ: Вы можете скачать проект Xcode здесь: http://github.com/d11wtq/Cioccolata

Я добавил цель модульного теста в свой проект XCode, но он не может найти мою платформу при сборке, говоря:

Test.octest could not be loaded because a link error occurred. It is likely that dyld cannot locate a framework framework or library that the the test bundle was linked against, possibly because the framework or library had an incorrect install path at link time.

Моя структура (основная цель проекта) предназначена для встраивания и поэтому имеет путь установки @executable_path/../Frameworks.

Я пометил инфраструктуру как прямую зависимость от цели теста и добавил ее на этапе сборки «Связать двоичные файлы с библиотеками».

Кроме того, я добавил первый шаг (после построения зависимости) «Копировать файлы», который просто копирует инфраструктуру в каталог Frameworks пакета модульного тестирования.

У кого-нибудь есть опыт по этому поводу? Я не уверен, что я пропустил.

РЕДАКТИРОВАТЬ | Я почти уверен, что не должен, так как фреймворк не является исполняемым, но я не установил «Test Host» и «Bundle Loader». Это должно (на мой взгляд) все быть в порядке, поскольку тестовый пакет связан с платформой и будет загружать его, как и любой другой пакет.

РЕДАКТИРОВАТЬ | Я думаю, что я почти там. Я прочитал следующую статью, которая диктует использование @rpath вместо @ executetable_path.

http://www.dribin.org/dave/blog/archives/2009/11/15/rpath/

В этом случае это имеет смысл, поскольку тестовый пакет OCUnit НЕ является исполняемым файлом, это обычный старый пакет, поэтому @executable_path несовместим. Так что теперь мой фреймворк имеет свой установочный каталог, установленный на @rpath, а цель теста имеет пути поиска во время выполнения (rpath), определенные как каталог сборки. Это избавляет меня от необходимости копировать фреймворк в тестовый пакет и означает, что в целом результирующий фреймворк гораздо более гибок по своей природе, поскольку может жить где угодно.

Теперь я также понимаю, что я должен установить Bundle Loader на цели Test, поэтому теперь он установлен на путь двоичного файла фреймворка.

Я могу построить тестовую цель и #import классов из фреймворка, без ошибок. Но как только я пытаюсь создать экземпляр класса из фреймворка, я получаю следующую ошибку:

/Developer/Tools/RunPlatformUnitTests.include:412: note: Started tests for architectures 'i386' /Developer/Tools/RunPlatformUnitTests.include:419: note: Running tests for architecture 'i386' (GC OFF) objc[50676]: GC: forcing GC OFF because OBJC_DISABLE_GC is set Test Suite '/Users/chris/Projects/Mac/Cioccolata/build/Debug/Test.octest(Tests)' started at 2010-05-21 12:53:00 +1000 Test Suite 'CTRequestTest' started at 2010-05-21 12:53:00 +1000 Test Case '-[CTRequestTest testNothing]' started. /Developer/Tools/RunPlatformUnitTests.include: line 415: 50676 Bus error "${THIN_TEST_RIG}" "${OTHER_TEST_FLAGS}" "${TEST_BUNDLE_PATH}" /Developer/Tools/RunPlatformUnitTests.include:451: error: Test rig '/Developer/Tools/otest' exited abnormally with code 138 (it may have crashed). Command /bin/sh failed with exit code 1

Мой тестовый метод не делает ничего, кроме выделения и последующего выпуска класса HelloWorld, который я создал для отладки этой настройки:

- (void)testNothing {
    CTHelloWorld *h = [[CTHelloWorld alloc] init];
    [h release];
}

Если я заменю эти строки кода на STAssertTrue(YES, @"Testing nothing");, ошибка исчезнет, ​​даже если класс все еще импортируется.

Ответы [ 6 ]

4 голосов
/ 24 мая 2010

Поскольку никто больше не вмешивался в этот вопрос, я в заключение скажу, что SenTestingKit действительно не впечатлил меня сложностью (и уродством) установки для моих нужд. Я настоятельно рекомендую GHUnit, который работает в пользовательском интерфейсе (или в командной строке, если вы предпочитаете) и поддерживает использование gdb из коробки. Мне понадобилось несколько минут, чтобы загрузить и использовать GHUnit в моем проекте.

Это тоже довольно. Apple должна поставлять его с Xcode вместо SenTestingKit ИМХО.

3 голосов
/ 15 ноября 2012

У меня была такая же проблема, но с фреймворком Kiwi Unit Testing. Моя проблема заключалась в том, что «Test Host» не был установлен в настройках сборки. Когда я установил его в $ (BUNDLE_LOADER), все работало отлично. Проверено с использованием Xcode 4.5.2 iOS SDK 6.0.

2 голосов
/ 25 сентября 2010

Это случилось со мной несколько раз. Я знаю, что вы переключились на GHUnit, но на тот случай, если кому-то это интересно: после долгого обхода я понял, что Xcode просто не добавляет классы кода (файлы .m) в часть Compile цели, но часть ресурсов копирования ресурсов. Перемещение в нужное место решило проблему.

1 голос
/ 23 октября 2010

Хорошо, я тоже боролся с этим, и вот что я нашел, это простое решение проблемы:

  1. Создайте приложение / фреймворк
  2. Создайте свой тестовый пакет «дополнительная цель», не устанавливайте зависимость от вашего основного
  3. Перетащите файлы, которые вы хотите протестировать, из своих классов в «исходники компиляции» вашей целевой группы тестов
  4. Создайте свои тестовые наборы, добавив их только в целевой набор тестов
  5. Скомпилируйте цель теста, тесты запустятся.

Обратите внимание, это означает, что вам просто нужно скомпилировать целевой набор тестов, когда вы хотите запустить свои тесты. Идеально, нет; работает, да.

Apple действительно автоматизирует это и работает правильно, из коробки.

1 голос
/ 19 мая 2010

Возможно, вам повезет со следующей статьей , в частности, добавление DYLD_FRAMEWORK_PATH и DYLD_LIBRARY_PATH в ваш исполняемый файл может помочь.

0 голосов
/ 18 июля 2011

Я согласен с рекомендациями для GHUnit, он просто потрясающий!

Однако я перешел на использование OCTest после того, как Apple интегрировала его в xCode4, так что я перебираю проблемы.

Проблема связывания, о которой здесь сообщалось, возникла у меня после того, как мы добавили новые файлы в проект. К ним относятся ViewControllers и xibs, но файлы были помечены в xcode как для приложения, так и для цели теста. Я обнаружил файлы, проверив комплект OCTest в каталоге производных данных. ~ / Библиотека / Разработчик / Xcode / DerivedData / Щелкните правой кнопкой мыши и выберите «Показать содержимое пакета» из поиска. Ищите вещи, которые там не принадлежат, а именно: классы приложений и ресурсы. Удаление этих файлов из «Источников компиляции» или «Копировать ресурсы комплекта» исправило ошибку компоновки.

...