iphone - unit - wenderlich ios

¿Por qué crear una instancia de UIFont en una prueba de unidad de iphone provoca un bloqueo?

Question

Estoy tratando de probar un poco el código del iPhone que crea fuentes. Lo he reducido a la siguiente prueba de unidad de choque:

#import "test.h"
#import <UIKit/UIKit.h>
@implementation test
- (void)testFonts {
[UIFont systemFontOfSize:12];
}
@end

Esto se bloquea con el error:

Test Case ''-[test testFonts]'' started.
/Developer/Tools/RunPlatformUnitTests.include: line 415: 79768 Trace/BPT trap "${THIN_TEST_RIG}" "${OTHER_TEST_FLAGS}" "${TEST_BUNDLE_PATH}"
/Developer/Tools/RunPlatformUnitTests.include:451: error: Test rig ''/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.1.sdk/Developer/usr/bin/otest'' exited abnormally with code 133 (it may have crashed).

Parece que hay alguna configuración que no estoy haciendo en mi objetivo de prueba de unidad para hacer que esto funcione. ¿Cómo pruebas unitarias de cosas que instancian las fuentes?

Answer 1

¿Lo has probado en el dispositivo? Me parece recordar que solo puedes incluir cosas de UIKit en las pruebas cuando se ejecutan en el dispositivo, no contra el simulador ...

Answer 2

Estoy viendo este problema exacto con 3.2 (y 3.1.3). Lo he visto en dos máquinas separadas, por lo que no creo que mi SDK esté dañado.

Creé un nuevo proyecto basado en la vista de iPhone y agregué una prueba de unidad y un caso de prueba.

Esto se configura como una prueba lógica.

La salida de la consola es la siguiente:

Test Case ''-[TestTests testTests]'' started.
/Developer/Tools/RunPlatformUnitTests.include: line 415: 21141 Trace/BPT trap "${THIN_TEST_RIG}" "${OTHER_TEST_FLAGS}" "${TEST_BUNDLE_PATH}"
/Developer/Tools/RunPlatformUnitTests.include:451: error: Test rig ''/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.1.3.sdk/Deve loper/usr/bin/otest'' exited abnormally with code 133 (it may have crashed).
Command /bin/sh failed with exit code 1

Si configuro la prueba de unidad para la depuración, entonces puedo ver el bloqueo, con el siguiente seguimiento de pila:

#0 0x00342d51 in __HALT
#1 0x002947c7 in _CFRuntimeCreateInstance
#2 0x00b8441e in GSFontCreateWithName
#3 0x028c8f31 in +[UIFont systemFontOfSize:]

Puedo ver el punto de Kendall (las cosas de UIKit solo funcionan en el dispositivo), pero eso no parece estar bien documentado en ninguna parte.

Answer 3

Lo siento por desenterrarlo, pero tengo un problema con la prueba XCT en Xcode 5 y está relacionado con este hilo

Citar:

"Muchas clases de UIKit no funcionarán sin la aplicación UIA. Al intentar agregar código para pasar las pruebas en este proyecto, se reveló que otras pruebas también deberían excluirse condicionalmente de LogicTests:

El método de loadView predeterminado fallará, por lo que el método testLoadView es # ifdef''d out.

Cualquier intento de asignar / iniciar un UILabel fallará. No sé por qué, pero debido a esto, todas las pruebas en las etiquetas deben ser # ifdef''d.

En general, no espere que nada del marco UIKit funcione en sus pruebas de Logic. Otros marcos casi siempre funcionarán (en esta aplicación, los marcos CoreLocation y Foundation funcionan sin problemas).

Dentro de UIKit, algunos elementos funcionarán, por ejemplo, UIWebView no tuvo ningún problema en mis pruebas. Exactamente qué objetos de la interfaz de usuario fallarán en el paquete de LogicTests (sin una aplicación real en ejecución) nunca es realmente claro hasta que lo intente, pero estas fallas son la razón por la que aún necesita ejecutar las Pruebas de la aplicación para verificarlas: las Pruebas de la aplicación son más autorizadas. Resultado para cualquier cosa en UIKit ".

URL: http://www.cocoawithlove.com/2009/12/sample-iphone-application-with-complete.html

Answer 4

No lo dice muy bien, pero el kit de prueba de Apple divide las pruebas unitarias en dos categorías separadas:

• Pruebas logicas

  Estas pruebas verifican la funcionalidad correcta de su código en un entorno de sala limpia.

• Pruebas de aplicación

  Estas pruebas verifican la funcionalidad de su código en una aplicación en ejecución.

Parece que hay un montón de código relacionado con la IU que no se puede ejecutar en el caso de "Prueba lógica". Más información sobre Pruebas lógicas vs Pruebas de aplicación aquí.

http://developer.apple.com/library/ios/#documentation/DeveloperTools/Conceptual/UnitTesting/01-Unit-Test_Overview/overview.html

Answer 5

Seleccione su objetivo de prueba de unidad en la sección "Objetivos" de la lista de proyectos / objetivos y en la sección "General" elija su aplicación Host como la aplicación principal, que tiene las fuentes.

Eso solucionó el problema para mí.

Answer 6

Uno de mis amigos se había encontrado recientemente con esto, y saqué el último proyecto en el que lo configuré con éxito. El truco consiste en ejecutar cualquiera de sus pruebas que impliquen UIFont en las pruebas de aplicación, en lugar de las pruebas unitarias. Aquí hay algunas cosas para asegurarse al configurar el objetivo de prueba de la aplicación:

1. CONSTRUIR FASES: Incorpore su código de producción a su objetivo de prueba al incluir su objetivo principal como una de las dependencias de su objetivo de prueba, en lugar de incluir los archivos .m en su objetivo de prueba. Esto es sólo para la organización.
2. CONSTRUIR CONFIGURACIONES: Asegúrese de que el "Cargador de $(BUILT_PRODUCTS_DIR)/Your Product Name.app/Your Product Name Again " de su objetivo de prueba esté configurado en $(BUILT_PRODUCTS_DIR)/Your Product Name.app/Your Product Name Again . Tome nota, es .../Product.app/Product - es decir, no hay .app en el segmento final de la ruta. Si tiene curiosidad por ver el archivo al que se refiere, busque su producto de compilación, haga clic con el botón derecho, seleccione Ver contenido del paquete y luego busque el archivo ejecutable.
3. CONFIGURACIÓN DE CONSTRUCCIÓN: el "Host de prueba" de su objetivo de prueba se debe establecer en $(BUNDLE_LOADER) . Pan comido.
4. CONSTRUIR AJUSTES: los indicadores de otros enlazadores del objetivo de prueba deben incluir -framework SenTestingKit .
5. CONFIGURACIÓN DE LA CONSTRUCCIÓN: "Prueba después de la construcción" debe ser No.
6. ESQUEMA: ''Crear'' debe incluir tanto su objetivo de prueba como su objetivo principal, con "prueba" la única casilla seleccionada en ambos objetivos.
7. ESQUEMA: ''Prueba'' debe incluir solo su objetivo de prueba. Los archivos que incluye se agregarán automáticamente a la lista.

... espero que esto sea suficiente para que todos ustedes se pongan en marcha. No todo está documentado de forma limpia en un solo lugar, y descubrir cómo realizar los dos tipos de pruebas llevó más tiempo y dolor del que quisiera admitir.

Es extraño que Apple parece haber derribado su propio documento sobre el asunto. Me pregunto si habrá otro cambio ...

Por favor, pégame si tienes alguna adición a lo anterior. No es una guía completa para configurar las pruebas de aplicaciones, pero lo anterior son los obstáculos sin documentación que encontré. FMI, recomiendo altamente este artículo de CocoaWithLove .