¿Cómo depurar una prueba de unidad en Xcode 3?

Question

Seguí el instructions de Apple para configurar las pruebas unitarias en mi proyecto. Seguí las instrucciones para hacerlos dependientes, por lo que las pruebas se ejecutan con cada compilación de mi proyecto principal. Esto funciona, y cuando pasan mis pruebas, la aplicación se ejecuta; cuando no lo hacen, obtengo errores de compilación en las líneas de las pruebas unitarias que fallaron.

Me gustaría, sin embargo, poder acceder al código de mi aplicación cuando las pruebas están fallando, pero no puedo configurar Xcode (3.2.5) correctamente. El proyecto es un proyecto Mac, no iOS.

probé las instrucciones here y here, pero la ejecución no se detuvo en los puntos de ruptura que puse, ni en el código de prueba de la unidad o en mi código de la aplicación. Después de seguir el primer conjunto de instrucciones, los puntos de interrupción que establecí se volvieron amarillos con contornos azules, y tampoco sé lo que eso significaba. ¿Qué debo hacer para superar mis pruebas?

actualización

he encontrado otra página de intentar resolver este problema (here) mediante la adición de argumentos y variables de entorno a mi ejecutable principal, pero de nuevo, los que no causó la ejecución de parada en mis puntos de interrupción. También noté que las instrucciones de registro de mi prueba (copiosas) no se muestran en mi consola de depurador tampoco.

También descubrí que los puntos de interrupción amarillos significan que el código no se puede encontrar en el tiempo de ejecución. Estos están en mi clase de caso de prueba, por lo que definitivamente parece explicar por qué no están disparando.

Answer 1

Lo único que terminó funcionando para mí fue la actualización a Xcode 4. Se integra maravillosamente. Hubo un little bit of pain al pasar a él, pero ahora que se acabó, la integración es genial. Soy completamente capaz de pasar por mis pruebas y el código de la aplicación.

Answer 2

desarrollan sus pruebas unitarias para que envuelvan un programa que reside en un proyecto que tiene un objetivo, luego simplemente abra el proyecto dependiente y trabaje en él. esto probablemente sería un proyecto con una biblioteca y un ejecutable que llama a través de la biblioteca (2 objetivos). entonces puede simplemente abrir el proyecto y depurar, mientras que las pruebas de su unidad en la dependencia llamarían a través de esta biblioteca. este es un enfoque más modular.

buena suerte

Answer 3

lo general tienen ningún problema para la depuración de mis pruebas OCTest con Xcode 3.2, incluido el abandono en los puntos de interrupción.

La idea básica es decirle a gdb que inicie otest con su paquete como argumento. Lo hará agregando /Developer/Tools/otest como ejecutable personalizado a su proyecto Xcode, luego el nombre del paquete OCTest como único argumento (elija "Editar activo ejecutable otest" en el menú Proyecto, y en la segunda pestaña agregue una línea con Foo.octest en el cuadro superior para depurar la prueba Foo).

Ahora, si presiona el botón de depuración, comenzará a depurar el paquete de prueba ahora mismo, y se detendrá en los puntos de corte declarados (si acierta compilación y depuración, puede no iniciarse si la prueba no se supera). También tenga en cuenta que tal vez tenga que establecer una variable de entorno en SÍ para deshabilitar la recolección de elementos no utilizados (en el cuadro de la parte inferior de la misma pestaña "Argumentos"), otest le dirá exactamente si lo necesita. Si hizo todo lo anterior y aún no puede ingresar su código de prueba, esto podría ser porque está compilado con la generación de símbolos de depuración desactivada - verifique la configuración de compilación, pero probablemente porque el código de prueba no recompilado en absoluto. Lo más probable es que, dado que sus registros no se muestran en la consola, NSLog debe escribir en la consola de Xcode. Limpie sus carpetas de compilación e bin de forma manual, a veces, cuando cambia una ruta o un nombre, termina cargando un código obsoleto. También es posible que desee verificar que el archivo no haya saltado del objetivo de prueba (¿es la prueba que falla en el mismo archivo que no está registrando?).

Answer 4

También probé las soluciones en los enlaces que proporcionó, pero ninguna funcionó para mí también. Pero luego encontré este: http://hiediutley.wordpress.com/2011/03/08/xcode3-debugging-ios-unit-tests/ - funciona como un encanto :) Cosas frescas, también.

Answer 5

Tengo una variante de lo que Hiedi Utley publicó en http://hiediutley.wordpress.com/2011/03/08/xcode3-debugging-ios-unit-tests/. Lo que no me gustó es la duplicación de los objetivos del paquete de prueba unitario, uno que contenía una fase Ejecutar script para ejecutar las pruebas unitarias después de construir y otro que no ejecutaba las pruebas unitarias. En el panel Obtener información de la fase Ejecutar guión, me di cuenta de que alternar "Ejecutar guión solo durante la instalación" y pensé que sería una forma de alternar entre ejecutar las pruebas unitarias en modo normal y ejecutarlas en el depurador.

Según las instrucciones de Hiedi, cree un nuevo elemento ejecutable, digamos LogicTestsGDB. Configurarlo de esta manera:

Ficha General:

• Path: Developer/usr/bin/otest (No se lleva /) Tipo
• Path: Relative to Current SDK
• Establecer el directorio de trabajo: Build Products directory

Argumentos Ta b:

• Argumentos: Su unittest Bundle (por ejemplo. LogicTests.octest)
• Variables de engaste para el medio ambiente
  • DYLD_LIBRARY_PATH ... : ${BUILD_PRODUCTS_DIR}:${DYLD_LIBRARY_PATH}
  • DYLD_FRAMEWORK_PATH . : ${SDKROOT}/Developer/Library/Frameworks
  • DYLD_ROOT_PATH ...... : ${SDKROOT}
  • IPHONE_SIMULATOR_ROOT : ${SDKROOT}
  • OBJC_DISABLE_GC : YES
  • DYLD_NEW_LOCAL_SHARED_REGIONS : YES
  • DYLD_NO_FIX_PREBINDING : YES
  • CFFIXED_USER_HOME : ${HOME}/Library/Application Support/iPhone Simulator/

Listo. Ahora, para depurar las pruebas unitarias,

1. Exponer las fases de construcción del lote y haga doble clic en el fase Ejecutar script.
2. Comprobar el guión Ejecutar sólo cuando la instalación opción
3. Ajuste el activo Objetivo ser el paquete de prueba de unidad (por ejemplo. LogicTests.octest).
4. Establecer la activo ejecutable a ser el nuevo ejecutable creado (por ejemplo. LogicTestsGDB)
5. Haga clic Construir y depuración

funcionando normalmente, la ejecución de pruebas unitarias como parte de la fase de construcción de la aplicación:

1. Exponer las fases de construcción del lote y haga doble clic en el fase Ejecutar script. Sólo
2. Deseleccionar el guión Run al instalar opción
3. Ajuste el activo Objetivo a ser la aplicación que se está construyendo
4. Ajuste el activo ejecutable a ser la aplicación que se está construyendo

Para automatizar los pasos anteriores, creé un script simple de AppleScript que alterna entre los dos estados:

property kApplicationName : "MyApp" -- name of the normal application to build 
property kUnitTestName : "LogicTests" -- name of the bundle target to debug 
property kUnitTestRunner : "LogicTestGDB" -- name of the executable to use when debugging the unit test bundle 

tell application "Xcode" 
    tell the active project document 
    set theTarget to first target whose name is kUnitTestName 
     set thePhase to first run script phase of theTarget 
     if name of active target is kApplicationName then 
      set active target to theTarget 
      set theExecutable to first executable whose name is kUnitTestRunner 
      set active executable to theExecutable 
      set run only when installing of thePhase to true 
     else 
      set theTarget to first target whose name is kApplicationName 
      set active target to theTarget 
      set theExecutable to first executable whose name is kApplicationName 
      set active executable to theExecutable 
      set run only when installing of thePhase to false 
     end if 
     return "Targeting " & (name of active executable) 
    end tell 
end tell