iphone - not - pruebas unitarias swift

Cómo ejecutar y depurar pruebas unitarias para una aplicación de iPhone

Question

NOTA: La prueba de la unidad es mucho más fácil de configurar en la actualidad. Este tutorial no es realmente relevante para Xcode versión 5 y superior.

Me tomó bastante tiempo, pero finalmente logré que funcionara para mi proyecto. Para crear las pruebas "lógicas" seguí las pautas de Apple para crear pruebas lógicas . Esto funciona bien una vez que entiendes que las pruebas lógicas se ejecutan durante la compilación.

Para poder depurar esas pruebas es necesario crear un archivo ejecutable personalizado que llame a esas pruebas. El artículo de Sean Miceli en el blog Grokking Cocoa proporciona toda la información para hacer esto. Sin embargo, seguirlo no produjo un éxito inmediato y necesitó algunos ajustes.

Repasaré los pasos principales que se presentan en el tutorial de Sean, con un resumen de "para tontos" que me llevó algo de tiempo descubrir:

1. Configure un objetivo que contenga las pruebas unitarias pero NO las ejecute
2. Configurar el mejor ejecutable para ejecutar las pruebas.
3. Configure las variables de entorno otest para que otest encuentre sus pruebas unitarias

Lo siguiente se realizó con XCode 3.2.5.

Nota para XCode 4

En XCode 4 es posible depurar las pruebas unitarias DIRECTAMENTE. Simplemente escriba su prueba, agréguela a su objetivo como una de las pruebas y establezca un punto de interrupción en ella. Eso es todo. Vendrán más.

Paso 1 - Configuración del objetivo

1. Duplique su objetivo de pruebas de unidad ubicado bajo los objetivos de su proyecto. Esto también creará un duplicado de su producto de pruebas unitarias (archivo .octest). En la siguiente figura, "LogicTest" es el objetivo original.
2. Cambie el nombre del destino de las pruebas unitarias y el producto de las pruebas unitarias (archivo .octest) con el mismo nombre. En la siguiente figura, "LogicTestsDebug" es el objetivo duplicado.
3. Eliminar la fase RunScript del nuevo objetivo.

El nombre de ambos puede ser cualquier cosa pero evitaría espacios.

Paso 2 - Configuración de otest

El punto más importante aquí es obtener la prueba correcta, es decir, la de tu iOS actual y no la versión predeterminada de Mac. Esto está bien descrito en el tutorial de Sean. Aquí hay algunos detalles más que me ayudaron a arreglar las cosas bien:

1. Ir Proyecto-> Nuevo ejecutable personalizado. Esto abrirá una ventana que le pedirá que ingrese un nombre ejecutable y una ruta ejecutable.
2. Escriba cualquier cosa que desee para el nombre.
3. Copie y pegue la ruta a su ejecutable iOS otest. En mi caso, esto fue /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator4.2.sdk/Developer/usr/bin/otest
4. Presione enter. Esto te llevará a la página de configuración de tu ejecutable.
5. Lo único que se debe cambiar en este momento es seleccionar "Tipo de ruta: Relativo al SDK actual". No escriba la ruta, esto se hizo en el paso 3.

Paso 3 - Configuración de los otros argumentos y variables de entorno

Los mejores argumentos son fáciles de configurar ... Pero este resultó ser mi mayor problema. Inicialmente había llamado a mi objetivo de prueba de lógica "LogicTests Debug". Con este nombre y "LogicTests Debug.octest" (con comillas) como argumento para evitar, seguí terminando con el código de salida 1 y NUNCA me detuve en mi código ...

La solución : ¡no hay espacio en el nombre de tu objetivo!

Los argumentos a tratar son:

1. -SenTest Self (o All o un nombre de prueba - escriba man otest en terminal para obtener la lista)
2. {LogicTestsDebug} .octest: donde {LogicTestsDebug} necesita ser reemplazado por el nombre de su paquete de prueba lógica.

Aquí está la lista de variables de entorno para copiar / pegar:

• DYLD_ROOT_PATH: $ SDKROOT
• DYLD_FRAMEWORK_PATH: "$ {BUILD_PRODUCTS_DIR}: $ {SDK_ROOT}: $ {DYLD_FRAMEWORK_PATH}"
• IPHONE_SIMULATOR_ROOT: $ SDKROOT
• CFFIXED_USER_HOME: "$ {HOME} / Library / Application Support / iPhone Simulator / User"
• DYLD_LIBRARY_PATH: $ {BUILD_PRODUCTS_DIR}: $ {DYLD_LIBRARY_PATH}
• DYLD_NEW_LOCAL_SHARED_REGIONS: YES
• DYLD_NO_FIX_PREBINDING: YES

Tenga en cuenta que también probé el DYLD_FORCE_FLAT_NAMESPACE pero esto simplemente hizo que se bloquee.

Paso 4 - Ejecutando tu ejecutable otest

Para ejecutar su ejecutable otest y comenzar a depurar sus pruebas, necesita:

1. Establezca su objetivo activo en su objetivo de prueba de unidad (LogicTestsDebug en mi caso)
2. Establecer su ejecutable activo a su otest ejecutable

Puede construir y ejecutar su ejecutable y depurar sus pruebas con puntos de interrupción.

Como nota al margen, si tiene problemas para ejecutar su ejecutable otest, puede estar relacionado con:

1. Camino defectuoso. Inicialmente tuve muchos problemas porque estaba apuntando al mac otest. Seguí estrellándome en el lanzamiento con el código de terminación 6.
2. Argumentos defectuosos. Hasta que eliminé el espacio del nombre del paquete (.octest) seguí teniendo otro fallo con el código de salida 1.
3. Ruta errónea en las variables de entorno. El tutorial de Sean tiene muchas preguntas de seguimiento que dan una idea de lo que intentaron otras personas. El conjunto que tengo ahora parece funcionar, así que te sugiero que comiences con esto.

Puede recibir algún mensaje en la consola que podría llevarlo a pensar que algo está mal con sus variables de entorno. Puede notar un mensaje con respecto a las referencias de CFP. Este mensaje no impide que las pruebas se ejecuten correctamente, por lo que no se centre en él si tiene problemas para ejecutar otras pruebas.

La última vez que todo funcione, podrá detenerse en los puntos de interrupción de sus pruebas.

Una última cosa...

He leído en muchos blogs que la principal limitación del XCode SenTestKit integrado es que las pruebas no se pueden ejecutar mientras se crea la aplicación. Bueno, como resulta que, de hecho, es bastante fácil de manejar. Simplemente necesita agregar el paquete de pruebas de Logic como una dependencia para su proyecto de aplicación. Esto asegurará que su paquete de pruebas lógicas esté construido, es decir, que todas las pruebas se ejecuten, antes de que se construya su aplicación.

Para hacer esto, puede arrastrar y soltar su paquete de pruebas lógicas en su objetivo de aplicación.

Answer 1

Pude ejecutar el caso de prueba en el depurador en los siguientes pasos simples:

1. Producto> Construir para> Pruebas
2. Ponga un punto de ruptura en parte de la prueba que desea depurar
3. Producto> Prueba

Esto está en Xcode 6.0.1 y parece mucho más conveniente que el procedimiento largo descrito anteriormente.

Answer 2

Esta publicación está pensada como un "Cómo hacer" más que una pregunta real. Por lo tanto, esta respuesta está destinada a permitirme marcar el "Cómo hacer" como "Respondido". Esto probablemente será marcado por la comunidad como irregular. Estoy preparado para sugerencias sobre dónde publicar futuros "Cómo hacer" artículos.

Una nota final sobre este tema. Para aquellos que todavía se preguntan si vale la pena escribir pruebas unitarias, definitivamente diría ¡Sí!

Actualmente estoy escribiendo una aplicación con CoreData y la recuperación de datos de un servicio web (análisis xml). El modelo completo se puede probar y depurar sin tener que:

1. ejecutar la aplicación real en el simulador o dispositivo. No tener que usar el dispositivo para ejecutar las pruebas es una gran ganancia de tiempo. Es la diferencia entre 2 minutos y 5 segundos por carrera.
2. sin la necesidad de crear vistas o controladores al probar el modelo. El desarrollo y las pruebas completas pueden centrarse en el modelo solo en la primera iteración. Una vez que el modelo se autoriza para la integración, el resto del desarrollo puede seguir.

Para depurar el análisis xml puedo simplemente usar archivos "codificados" que controlo completamente.

El quid es, por supuesto, escribir las pruebas a medida que implementa funciones en el código. Realmente es un ahorro de tiempo en la línea en términos de depuración de la aplicación completa.

Voilà, lo dejo así.