Mejores prácticas sobre cómo incluir pruebas unitarias en una biblioteca

Question

Estoy trabajando en una biblioteca de código general para ActionScript 3.0 llamada as3lib que incluye varias extensiones de la API principal y algunas funciones útiles.He escrito varias pruebas unitarias (usando FlexUnit) para asegurarme de que todo funcione correctamente.

¿Cuál es la mejor manera de organizar estas pruebas en la biblioteca? Actualmente, tengo todo mi código en src/ y mis pruebas en test/ pero configuré un proyecto Flex secundario para ejecutar las pruebas unitarias.También agrego y elimino manualmente los archivos de prueba de la biblioteca cuando quiero ejecutar las pruebas.

Lo que estoy haciendo no parece correcto.¿Existe una mejor manera?Preferiblemente uno donde la biblioteca compilada no incluya los archivos de prueba pero no necesito dos proyectos separados para probarlos.

Answer 1

La forma en que hemos hecho estas cosas en mi empresa es que en realidad incluimos ambos bajo el directorio de origen, y entonces tenemos dos archivos MXML de la aplicación que utilizamos. Una de ellas es la suite de pruebas, que incluye todos los enlaces correspondientes a las clases de prueba de unidad, la otra es la aplicación principal. También hemos tener dos estructuras de paquetes dentro de la carpeta src: un paquete estructura com .., y otra tests.com ... Asegúrese de que TODO código fuente para las pruebas unitarias son Siempre en el paquete de pruebas - de esta manera se puede utilizar sólo una SVN ignorar, y también puede asegurarse de que sus pruebas no crean relaciones de dependencia y no modificable con otros proyectos

.

Hay dos maneras que utilizamos para garantizar que los archivos de origen test.com no están incluidos. El sistema automático de generación sólo hace referencia a la aplicación principal, y desde que sólo las importaciones de com., Mxmlc.exe sólo incluirá los archivos de la aplicación principal. Cuando la construcción a nivel local, en el interior del eclipse, se puede controlar la acumulación de cosas haciendo clic en la pequeña flecha al lado de depuración y vaya a "Organizar favoritos." Al hacer clic en "Añadir", debe ser capaz de seleccionar todos los archivos .mxml nivel raíz que hacen referencia a la clase de aplicaciones. Asegúrese de añadir la aplicación base y el nuevo archivo de la aplicación de prueba de unidad. Cuando hace clic en "OK", la flecha que ahora permite depurar ya sea como la aplicación principal, o su marco de unidad de prueba.

Como acotación al margen, también utilizamos FlexUnit como nuestro marco de pruebas. Me gusta mucho.

Answer 2

lo he hecho similar a la forma en que usted describe en el pasado, pero parece que el tipo de cosas donde SpringAS podría venir en muy útil para agregar y retirarlos de la configuración de forma dinámica. ¿Ha intentado mirar en eso?

Answer 3

Tenemos directorios src y tests separados en el nivel superior de nuestras bibliotecas.Nuestras aplicaciones son envoltorios muy finos para proyectos de biblioteca, por lo que no necesitan ninguna prueba.También contamos con un proyecto de aplicación FlexUnit, para ejecutar las pruebas desde FlexBuilder.

Usamos maven para nuestro sistema de compilación principal y el complemento Sonatype Flex ejecuta todas nuestras pruebas unitarias durante la compilación, incluso en nuestro servidor Continuum basado en Linux.Por defecto, Maven busca pruebas en un directorio de 'pruebas', lo que fue una buena justificación para elegir esa ubicación.

Answer 4

Me voy a ir contra la corriente aquí y sugerir la creación de un proyecto totalmente diferente para sus pruebas. Creo que en general, que en realidad no importa donde pones las pruebas, siempre que sea consistente y algo manejable. Sin embargo, para mí hay tres razones de peso para tener un proyecto separado para las pruebas:

1. La separación de preocupaciones. En primer lugar, la biblioteca tiene un propósito, las pruebas de tener otro. Mientras que las pruebas de las necesidades de la biblioteca a la función, la biblioteca tiene ninguna utilidad real para las pruebas. Nota: pruebas de que no estoy diciendo que no sirven para nada, ni mucho menos. Las pruebas están ahí para verificar la salud de la biblioteca, pero en un entorno de producción las pruebas no sirven a ningún propósito.

2. Menos hinchazón, archivos más pequeños. Las pruebas no siempre son triviales. Pero incluso si todos ellos eran, todavía estarían utilizando espacio en disco. Dado que las pruebas no se utilizan en un entorno de producción de todos modos, esto no tiene sentido. Además, la separación de las pruebas en un nuevo proyecto hace que la estructura de archivos mucho más limpio.

3. entornos de CI son generalmente más limpio para configurar cuando las pruebas no están alrededor.

Mientras que es ciertamente posible, al menos, a resolver el segundo problema con las directivas del compilador, es un trabajo innecesario cuando es mucho más fácil simplemente separar los dos. Probar una biblioteca o aplicación que puede que tenga que utilizar el mismo espacio de nombres (clases internas alguien?) Tampoco es un problema, ya que sus pruebas de proyecto puede reflejar los espacios de nombres. Obviamente, esto hace que sea necesario para no tener conflictos de nombres en los espacios de nombres, pero eso es trivial.

En términos de soporte de Flash Builder es genial para separar las cosas en dos proyectos. Todo lo que necesita hacer para crear una nueva prueba es botón derecho del ratón cualquier clase que instalacciones a prueba, pregunte para crear una nueva prueba y asegurarse de elegir sus pruebas de proyecto en lugar de la corriente en el cuadro de diálogo que aparece. Eso es realmente la razón principal por mí y miembros de mi equipo tenía un tiempo difícil justificar las pruebas de escritura cuando entramos en TDD, demasiado trabajo sólo para empezar. Con el estado actual de la IDE, es ridículamente simple y útil.

Como con cualquier técnica, sin embargo, hay advertencias. Por un lado, no es obvio que las pruebas están en un proyecto diferente a menos que esté documentado. Tener las pruebas en el mismo proyecto ordena efectivamente ese problema. Por otra parte, esto se resuelve fácilmente mediante la configuración experta u otras herramientas de administración de dependencias que pueda tener en su entorno. Otra cuestión es que si usted tiene una estructura de paquetes en sus pruebas de proyecto que refleja la de la biblioteca o de la aplicación, hay un poco de sobrecarga de mantenimiento en tener esas estructuras sincronizadas. Aunque no es un problema enorme y muy fácilmente resueltos mediante secuencias de comandos, es todavía vale la pena mencionar.

En cualquier caso, así es como lo hago.