OCUnit тестирует встроенный фреймворк

Question

ОБНОВЛЕНИЕ: я закончил тем, что сдался и добавил 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 вместо @executable_path.

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

В этом случае это имеет смысл, поскольку тестовый пакет OCUnit НЕ является исполняемым файлом, это обычный старый пакет, поэтому @executable_path не совместим. Так что теперь мой каркас имеет свой установочный каталог установлен в @rpath и у цели Test есть пути поиска во время выполнения (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"); ошибка исчезнет, ​​хотя класс все еще импортируется.

Answer 1

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

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

Answer 2

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

Answer 3

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

Answer 4

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

Answer 5

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

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

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

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

Answer 6

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

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

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