2009-08-23 23 views
5

Todavía no soy un fanático de los entornos de desarrollo integrados, pero estoy tratando de superar mis prejuicios y aprender Xcode. (Eclipse/CDT es el siguiente; no pude conseguir que funcionara para mí tampoco cuando lo intenté el año pasado, pero eso es un problema aparte.)¿Cómo organizar las pruebas unitarias de un proyecto de biblioteca en Xcode?

Estoy escribiendo un nuevo código en un nuevo proyecto que se convertirá en (parte de) una pequeña biblioteca. Quiero probarlo en una unidad también. ¿Cómo le explico a Xcode que estoy creando una biblioteca (compartida), pero también quiero usarla en un programa de prueba, compilado de una fuente separada que no estará en la biblioteca compartida?

Código Fuente:

  • atom.c
  • atom.h
  • prueba atom.c

archivos fabricados:

  • libatom.dylib
  • test-atom

Tengo atom.c y atom.h compilados en la biblioteca. Simplemente no estoy seguro de cómo organizar las cosas para que también pueda compilar test-atom para vincular con la biblioteca. Supongo que cuando haya ordenado eso, agregar la biblioteca para el código de soporte de prueba que test-atom.c sería relativamente sencillo, aunque todavía no esté bajo el control de Xcode.

Fwiw, que trabajan principalmente en C en lugar de C. Objetivo

Respuesta

4

Necesita dos objetivos en su proyecto; un objetivo en Xcode produce un producto que es una biblioteca, ejecutable u otra salida.

Por lo tanto, tendría un objetivo para producir libatom.dylib, que sospecho que ya ha configurado, y otro objetivo ejecutable de línea de comandos para producir el ejecutable test-atom para ejecutarlo para probar su biblioteca.

vez que haya añadido el objetivo test-atom, debe Obtener información en test-atom.c y remover a su pertenencia del objetivo libatom.dylib y añadirlo como un miembro de su nueva test-atom objetivo. La membresía objetivo de un archivo es lo que determina si la creación de un destino intentará compilar/copiar/vincular ese archivo. (Lo que el destino hace con el archivo depende de qué fase de construcción que se agrega a cuando se hizo un miembro.)

También debe Obtener información en la entrada libatom.dylib en su grupo de productos, y hacer que un miembro de el objetivo test-atom también. Eso hará que el ejecutable test-atom se vincule con libatom.dylib.

Por último, en Obtener información en el test-atom objetivo (no el producto) y en la ficha General, agregue una dependencia en el objetivo libatom.dylib. Esto asegurará que la construcción del objetivo test-atom siempre construirá primero el objetivo libatom.dylib.

2

Editar: Ver Automated Unit Testing with Xcode 3 and Objective-C (una versión más reciente del artículo enlazado originalmente, como se señaló en un comentario más abajo). También vea What is the best way to unit test Objective-C code? Si bien claramente no está usando Obj-C todavía, los conceptos básicos para establecer nuevos objetivos serán los mismos para el código C, y el material específico de OCUnit es muy representativo de cómo funciona la prueba unitaria en un IDE.

+4

No apunte a las personas a "Probar el código con OCUnit": está obsoleto y ha quedado muy desactualizado desde un par de meses después de su publicación. Por un lado, le dice a las personas que descarguen OCUnit, pero OCUnit se ha incluido con Xcode desde la WWDC 2005 cuando se lanzó Xcode 2.1. Indique a las personas "Pruebas unitarias automatizadas con Xcode 3 y Objective-C" http://developer.apple.com/mac/articles/tools/unittestingwithxcode3.html. –

+0

¡Gracias por señalar el nuevo artículo! –

Cuestiones relacionadas