2009-01-05 14 views
6

Para fines de pruebas unitarias, me gustaría crear un objetivo de proyecto de iPhone en Xcode que incluya todos los archivos de la aplicación de lanzamiento, además de algunos archivos adicionales que contienen código útil para las pruebas de unidades de IU.¿Se puede crear un objetivo "superconjunto" en Xcode?

Puedo hacerlo duplicando el objetivo de la aplicación original; sin embargo, el problema con esto es que cada vez que agrego un nuevo archivo fuente al destino de la aplicación, también necesito agregarlo al objetivo UnitTestUI. No es gran cosa, solo es un inconveniente recordar siempre agregar archivos a ambos objetivos.

¿Hay alguna forma de configurar una dependencia para que cada archivo agregado al destino de la aplicación original también se agregue automáticamente al objetivo de prueba de la unidad?

Respuesta

4

En Xcode, puede crear objetivos que tengan dependencias directas entre sí. Hay una serie de objetivos de creación de productos que pueden ayudar con esto en la categoría Otros al agregar un nuevo objetivo, dependiendo de qué tan simple o complicado sea su configuración. La creación de objetivos específicos para ejecutar pruebas unitarias con una dependencia directa del objetivo principal del proyecto es muy común y está documentada por Apple y en varios blogs.

En su caso, sin embargo, es posible que tenga que hacer muchos ajustes en el nuevo objetivo de prueba de UI, pero una vez que esté configurado, será muy fácil de mantener. Sin saber su situación exacta, es imposible para darle una respuesta paso a paso, pero aquí están las directrices generales (ajustar para adaptarse a su situación):

  1. Cree la copia de su objetivo original, ya que la mayor parte de su la configuración será la misma.
  2. Seleccione su nuevo objetivo y abra el inspector (⌘I)
  3. Bajo dependencias directas, haga clic en el botón + y seleccione su objetivo principal.
  4. Configure el nuevo destino según lo desee, con documentación/fuente/reglas adicionales o lo que sea.

Si prefiere arrastrar y soltar las cosas, también puede arrastrar a su objetivo original (por debajo de los objetivos triángulo desplegable) en su nuevo destino y que se configure automáticamente la dependencia.

Ahora, seleccione su objetivo de prueba como el objetivo activo y siempre se compilará con esas reglas. Además, si agrega/cambia la fuente en el objetivo principal, se reconstruirá adecuadamente al construir su objetivo de prueba ... no es necesario recordar agregar un archivo fuente al objetivo de prueba también. Sugiero tomarse un tiempo para leer los diversos documentos de Xcode y jugar con muchas de las plantillas de destino disponibles ... a largo plazo, realmente ayuda a que el uso del producto sea mucho más eficiente. Hay muchas cosas ingeniosas que se pueden hacer con bastante facilidad en Xcode si sabes cómo, incluso con proyectos muy grandes o complejos.

+1

¡Muchas gracias por esta respuesta tan útil! – thrusty

+0

Gran respuesta. Originalmente, pensé que también podía eliminar mis bibliotecas vinculadas del nuevo objetivo, pero nada de lo que '' git reset --hard''s no arreglaría. –

0

No, no. ¿Hay alguna razón particular por la que desee que cada archivo en su objetivo de prueba de unidad? Esto incluiría main.m y todas las clases que no está probando (como quizás sus clases de vista). De hecho, si main.m se incluye en su Prueba de unidad, ¿cómo funcionaría su prueba de unidad incluso correctamente?

+0

Debo aclarar que este objetivo está destinado a probar código que depende de tener todo el contexto de la aplicación disponible. (Como algunos UIViewControllers). Como tal, se parece más a un marco de prueba de UI, y está destinado a cubrir cosas que nuestros otros exámenes de unidades "sin cabeza" no pueden cubrir. – thrusty

+0

Claro que existe, los objetivos pueden ser dependencias directas entre sí. –

0

Resolví el problema construyendo la mayor parte de mi aplicación como biblioteca estática, que está vinculada a los objetivos de prueba de la aplicación y la unidad.

objetivos en mi proyecto se parecen:

  • libMyApp
    • compilar archivos .m
  • MyApp.app
    • libMyApp (dependencia)
    • Enlace con la biblioteca: libMyApp.a
  • UITest.app
    • libMyApp (dependencia)
    • Enlace con la biblioteca: libMyApp.a

De esta manera puedo añadir .m archivos sólo a la meta "libMyApp" y hacer que se disponible tanto en la aplicación como en las pruebas, y ni siquiera tienen que volver a compilarse.

El único problema es que la biblioteca estática no parece ser compatible con las categorías de Objective-C, por lo que aún tengo que agregarlas a cada objetivo por separado.

Cuestiones relacionadas