OCUnit probando un marco incrustado

Question

ACTUALIZACIÓN: terminé por renunciar y agregué GHUnit a mi proyecto en su lugar. Me puse en funcionamiento con GHUnit en cuestión de minutos.

ACTUALIZACIÓN: Se puede descargar el proyecto de Xcode aquí: http://github.com/d11wtq/Cioccolata

He añadido un blanco de ensayo Unidad a mi proyecto Xcode pero no logra encontrar mi marco cuando se acumula, diciendo:

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.

Mi marco (el objetivo principal del proyecto) está diseñado para ser incrustado y también tiene una ruta de instalación de @executable_path/../Frameworks.

He marcado el marco como una dependencia directa del objetivo de prueba y lo he agregado a la fase de compilación "Enlace binario con bibliotecas".

Además he agregado un primer paso (después de que se ha creado la dependencia) de "Copiar archivos" que simplemente copia el marco en el directorio de Frameworks del conjunto de pruebas de unidades.

¿Alguien tiene alguna experiencia en esto? No estoy seguro de lo que me he perdido.

EDIT | Estoy bastante seguro de que no se debe, ya que un framework no es ejecutable, pero no he configurado "Test Host" y "Bundle Loader". Esto (en mi opinión) debería estar bien, ya que el paquete de prueba está vinculado al marco y lo cargará igual que cualquier otro paquete.

EDIT | Creo que estoy cerca. Leí el siguiente artículo que dicta el uso de @rpath en lugar de @executable_path.

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

En este caso, tiene mucho sentido ya que el paquete de prueba OCUnit no es un archivo ejecutable, que es un paquete simple y llano, por lo @executable_path no es compatible. Así que ahora mi framework tiene su directorio de instalación establecido en @rpath y el objetivo Test tiene sus rutas de búsqueda en tiempo de ejecución (rpath) definidas como el directorio de compilación. Esto me ahorra tener que copiar el marco en el paquete de prueba y significa que, en general, el marco resultante es mucho más flexible en naturaleza, ya que puede vivir en cualquier lugar.

Ahora, también me doy cuenta de que 0 debería haber configurado el Bundle Loader en el objetivo de prueba, por lo que ahora está configurado en la ruta del binario de estructura.

Puedo construir el objetivo de la prueba y puedo importar las clases del marco, sin errores. Pero tan pronto como trato de crear una instancia de una clase desde el marco me sale el siguiente error:

/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

Mi método de prueba no hace más que asignar y liberar posteriormente una clase HelloWorld he creado para ayudar a depurar esta configuración:

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

Si puedo reemplazar estas líneas de código con una STAssertTrue(YES, @"Testing nothing"); el error desaparece, a pesar de que la clase sigue siendo importado.

Answer 1

Como nadie más ha intervenido en esta cuestión, terminaré diciendo que SenTestingKit realmente me impresionó con la complejidad (y fealdad) de la configuración para mis necesidades. Recomiendo encarecidamente GHUnit, que se ejecuta en una interfaz de usuario (o en línea de comandos, si lo prefiere) y admite el uso de gdb de fábrica. Me llevó unos minutos descargar y usar GHUnit en mi proyecto.

Es bonito también. Apple debería enviarlo con Xcode en lugar de SenTestingKit en mi humilde opinión.

Answer 2

Puede tener un poco de suerte con el siguiente article, en particular agregar DYLD_FRAMEWORK_PATH y DYLD_LIBRARY_PATH a su ejecutable podría ayudar.

Answer 3

Me pasó algunas veces. Sé que cambiaste a GHUnit, pero solo en caso de que alguien esté interesado: después de pasar por esto MUCHO tiempo, me di cuenta de que Xcode simplemente no agregaba las clases de código (archivos .m) en la parte de compilación del objetivo, sino en la parte de Copy Resources del objetivo. Moverlo al lugar correcto resolvió el problema.

Answer 4

Ok, así que yo también luché con esto, y esto es lo que he encontrado para ser la solución simple al problema:

1. Crear su aplicación/marco
2. Cree su paquete de prueba "objetivo adicional ", no establezca una dependencia en su principal
3. Arrastre los archivos que desea probar de sus clases a las" fuentes de compilación "de su paquete de prueba objetivo
4. Cree sus casos de prueba, agregándolos solo al objetivo del paquete de prueba
5. compilar objetivo de prueba, ejecutar pruebas.

Tenga en cuenta que esto significa que simplemente tiene que compilar el objetivo del paquete de prueba cuando desea ejecutar las pruebas. Ideal, no; funciona, si

Apple realmente automatiza esto y lo hace funcionar correctamente, listo para usar.

Answer 5

Estoy de acuerdo con las recomendaciones para GHUnit, ¡es totalmente genial!

Sin embargo, he cambiado al uso de OCTest después de que Apple lo integró en xCode4, así que estoy repasando los problemas.

El problema de enlace informado aquí se produjo después de que agregamos nuevos archivos al proyecto. Estos incluyen ViewControllers y xibs, pero los archivos fueron marcados en xcode tanto para la aplicación como para el objetivo de la prueba. Descubrí los archivos al inspeccionar el paquete OCTest en el directorio de datos derivado. ~/Library/Developer/Xcode/DerivedData/Haz clic con el botón derecho y selecciona "Mostrar contenido del paquete" desde el buscador. Busque cosas que no pertenecen allí, es decir: clases de aplicaciones y recursos. La eliminación de estos archivos de "Fuentes de compilación" o "Copiar recursos de paquete" corrigió el error de enlace.

Answer 6

Tuve el mismo problema pero con el marco de Kiwi Unit Testing. Mi problema era que "Test Host" no estaba configurado en Build Settings. Cuando lo configuré en $ (BUNDLE_LOADER), todo funcionó a la perfección. Verificado con Xcode 4.5.2 iOS SDK 6.0.