¿Cómo puedo ejecutar OCUnit (SenTestingKit) con NSDebugEnabled, NSZombieEnabled, MallocStackLogging?

Tengo un error similar al de esta publicación . Ahora, estoy seguro de que cometí algún error estúpido en algún lado, probablemente relacionado con la liberación de un object o un observador o lo que no, pero como parece que no puedo encontrar una manera de depurar el código, pensé que podría usar el NSDebugEnabled, NSZombieEnabled y MallocStackLogging (como se muestra aquí ).

¿Se puede hacer usando OCUnit? ¿Si es así, cómo? Simplemente no puedo encontrar un "ejecutable" para configurar estos parameters en …

¡Gracias! Aviad

Desafortunadamente, la solución de Dave no funcionó, seguí recibiendo errores y errores. Finalmente conseguí que GHUnit trabajara en mi proyecto, encontré el problema depurando, pero tenía sus propios problemas, por lo que ahora lo uso tanto como OCUnit, que está ligeramente mejor integrado en términos de mostrar los resultados en la pestaña de resultados.

suspiro ¿Cuándo podremos ver un marco de testings de unidad completo y bueno para Obj-C?

Esto puede haber sido arreglado en los Xcodes recientes, pero me sale zombis haciendo

  1. Ir a esquemas (cmd <)
  2. Prueba abierta, luego pestaña Argumentos
  3. Desactive la casilla "Utilizar los arguments de la acción Ejecutar y las variables de entorno"
  4. "+" una variable de entorno "NSZombieEnabled" = "SÍ"

Bueno, NSZombieEnabled y amigos son variables de entorno, lo que significa que deben ejecutarse en un ejecutable. La configuration pnetworkingeterminada para un package de testing de unidad es que las testings se ejecuten durante el process de compilation , y no durante la ejecución.

Entonces, la forma de solucionar esto es hacer que sus testings no se ejecuten durante la fase de compilation, sino que las ejecuten como parte de un ejecutable.

Así es como hago eso:

  1. Dentro de su objective de package de testing de unidad, elimine la fase de compilation "Ejecutar script". Es ese paso que ejecuta las testings después de comstackrlas.
  2. En el menu Proyecto, elija "Nuevo ejecutable personalizado …" y asígnele un nombre significativo, como "otest"
  3. Haga que la ruta ejecutable sea el otest binary, que debe ubicarse en /Developer/Tools/otest
  4. Establezca las siguientes variables de entorno en el otest ejecutable:
    • DYLD_FRAMEWORK_PATH => {UnitTest.bundle}/Contents/Frameworks
    • DYLD_LIBRARY_PATH => {UnitTest.bundle}/Contents/Frameworks
  5. Establezca los siguientes arguments de progtwig en el otest ejecutable:
    • -SenTest All (esto ejecutará todas las testings de unidad)
    • {UnitTest.bundle}

Ahora puede seleccionar su package de testing de unidad como el objective activo, y el otest ejecutable como el ejecutable activo, y luego comstackr y depurar. Esto le permitirá establecer puntos de interrupción, establecer otras variables de entorno (como NSZombieEnabled ), y así sucesivamente.

Si solo desea depurar una determinada suite o testing de unidad específica, puede cambiar el argumento -SenTest All a -SenTest MyUnitTestSuite o -SenTest MyUnitTestSuite/myUnitTestMethod .

Me llevó bastante time, pero finalmente logré que funcione para mi proyecto. Para crear las testings de "lógica" seguí las pautas de Apple sobre la creación de testings lógicas . Esto funciona bien una vez que comprende que las testings de lógica se ejecutan durante la compilation.

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

Repasaré los pasos principales que se presentan en el tutorial de Sean proporcionando algunos esquemas "para dummies" que me tomaron un time para descubrir:

  1. Configura un objective que contiene las testings de unidad pero NO las ejecuta.
  2. Configurar el file ejecutable otest para ejecutar las testings
  3. Configure las otras variables de entorno para que otest pueda encontrar las testings de su unidad.

Paso 1 – Configurar el objective

  1. Duplique el objective de testings de su unidad ubicado debajo de los Objetivos del proyecto. Esto también creará un duplicado del producto de testing de su unidad (file .octest). En la figura a continuación "UnitTest" es el objective original.
  2. Cambie el nombre del objective de las testings unitarias y el producto de las testings unitarias (file .octest) al mismo nombre. En la figura a continuación "UnitTestsDebug" es el objective duplicado.
  3. Eliminar la fase RunScript del nuevo objective

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 get el otest correcto, es decir, el de su iOS actual y no la versión pnetworkingeterminada de Mac. Esto está bien descrito en el tutorial de Sean. Aquí hay algunos detalles más que me ayudaron a arreglar las cosas:

  1. Ir proyecto-> Nuevo ejecutable personalizado. Esto abrirá una window que le pedirá que ingrese un nombre ejecutable y una ruta ejecutable.
  2. Escriba lo que desee para el nombre.
  3. Copie y pegue la ruta de acceso a su otest ejecutable. En mi caso, esto era /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator4.2.sdk/Developer/usr/bin/otest
  4. Presione enter. Esto lo llevará a la página de configuration de su file ejecutable.
  5. Lo único que hay que 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 – Configurar los otros arguments y variables de entorno

Los otros arguments son fáciles de configurar … Pero este fue mi mayor problema. Inicialmente había llamado a mi objective de testing lógica "LogicTests Debug". Con este nombre y "LogicTests Debug.octest" (con comillas) como argumento para otest, seguí habiendo terminado con el código de salida 1 y NUNCA deteniéndome en mi código …

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

Los arguments para otest son:

  1. -SenTest Self (o All o un nombre de testing – escribe el nombre de usuario en el terminal para get la list)
  2. {LogicTestsDebug} .octest – Donde {LogicTestsDebug} necesita ser reemplazado por su nombre de package de testing lógica.

Aquí está la list de variables de entorno para copyr / 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: SÍ
  • DYLD_NO_FIX_PREBINDING: SÍ

Tenga en count que también probé el DYLD_FORCE_FLAT_NAMESPACE pero esto simplemente causó un fallo mayor.

Paso 4: Ejecución de su file ejecutable otest

Para ejecutar su file ejecutable otest y comenzar a depurar sus testings, debe:

  1. Establezca su objective activo en su objective de testing de unidad (LogicTestsDebug en mi caso)
  2. Establezca su file ejecutable activo en su file ejecutable otest

Puede crear y ejecutar su ejecutable y depurar sus testings con puntos de interrupción.

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

  1. Ruta defectuosa Tuve muchos problemas inicialmente porque estaba apuntando a la mac otest. Seguí estrellándose en el lanzamiento con el código de terminación 6.
  2. Argumentos defectuosos Hasta que eliminé el espacio del nombre del package (.octest), seguí teniendo problemas con el código de salida 1.
  3. Ruta equivocada en las variables de entorno. [Sean tutorial] [8] tiene muchas preguntas de seguimiento que dan una idea de lo que intentaron otras personas. El set que tengo ahora parece funcionar, por lo que sugiero que comience con esto.

Es posible que reciba un post en la console que lo lleve a pensar que algo va mal con sus variables de entorno. Puede notar un post sobre CFPreferences. Este post no impide que las testings se ejecuten correctamente, así que no te centres en ello si tienes problemas al ejecutar otest.

Una vez que todo está funcionando, podrás detenerte en los puntos de interrupción en tus testings.

Una última cosa…

He leído en muchos blogs que la principal limitación del XCode SenTestKit integrado es que las testings no se pueden ejecutar mientras se genera la aplicación. Bueno, resulta que esto es bastante fácil de manejar. Simplemente debe agregar su package de testings lógicas como una dependencia a su proyecto de aplicación. Esto asegurará que su package de testings lógicas esté construido, es decir, todas las testings se ejecuten, antes de que se cree su aplicación.

Para hacer esto, puede drag and drop su package de testing lógica en su objective de aplicación.