ОБНОВЛЕНИЕ: я закончил тем, что сдался и добавил 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");
, ошибка исчезнет, даже если класс все еще импортируется.