2010-04-25 15 views
5

Tengo varios archivos con código de prueba de código (que utiliza una clase "unittest").¿Cómo organizar las pruebas de integridad de datos en vivo y las pruebas de unidad de código?

Más tarde descubrí que sería bueno probar la integridad de la base de datos también. Puse esto en un árbol de directorio por separado. (Cosas como que las teclas tienen el formato correcto, los nodos padre e hijo apuntan correctamente y tal. Edición: este es un proyecto nosql, donde no puedo confiar en las comprobaciones del nivel de base de datos de la integridad referencial y tal.)

Uso el misma clase de prueba individual para las pruebas de integridad.

Ahora me pregunto si tiene mucho sentido mantener esto separado. Para probar la integridad de los datos, a menudo duplico partes del código que utilizo para probar el código que maneja los datos.

Pero no es lo mismo. Las pruebas de código usan bases de datos de prueba (que se eliminan después de cada prueba) y las pruebas de integridad se conectan a los datos en vivo y lo analizan. Las pruebas de integridad quiero llamar desde cron y enviar una alarma si algo sucede en la base de datos en vivo.

¿Cómo manejarías eso? ¿Hay estándares para tal configuración? ¿Cuál es tu experiencia?

Mi tendencia es poner todo en el mismo archivo, lo que daría como resultado que el cron también ejecute las pruebas de código en el entorno de producción.

Edit: Lo que también me motiva es tratar de mantener el proyecto simple y no tener demasiados archivos tocados por una sola tarea o flujo de trabajo. Sin todas las pruebas, ya tengo un archivo de clase, una subclase, una clase relacionada, algunos archivos de biblioteca (auxiliar) y el código principal. Las pruebas agregan un archivo. Me ayuda a mantener mi atención enfocada durante la codificación, es menos estresante y creo que cometo menos errores, y puedo recordar más rápido y encontrar una parte de código determinada con menos archivos afectados. Solo un archivo de prueba por flujo de trabajo ayudaría aquí. Si lo mantengo separado, hay 2 archivos (prueba de integridad de datos y prueba de código) y tal vez 3 (una biblioteca común para ambos). La abstracción agregaría complejidad.

Edit2: ahora estoy refactorización un poco y sólo mover los archivos de pruebas de datos en el mismo árbol de directorios donde también el código de prueba de vida, pero manteniendo diferentes archivos con el nombre que indica la "integridad" o "probar". No (todavía) fusionaré los archivos, porque 2 personas recomendaron no hacerlo, y por el momento creo en su experiencia y consejo. Viviré con duplicación de código por el momento.

Edit3: Olvidé mencionar que la selección de las pruebas por ejecución no está determinada por la estructura del árbol en este caso. Las pruebas se enumeran en un archivo maestro, por lo que tengo 2 archivos maestros "integridad" y "prueba de código" en el presente, y la prueba puede vivir en la misma estructura directiva.

Tal vez más personas responderán. ¡Gracias por la valiosa contribución, que ya me está ayudando a desarrollar la estructura final!

Edit4: Hice más refactorización ahora. Parece que debería conservar 2 archivos, pero con un propósito ligeramente modificado. Uno destinado a la supervisión programada en el servidor de producción. Y otro para el desarrollo. Pero en ambos archivos pueden ser pruebas de integridad o pruebas de código. Y en ambos archivos las operaciones se pueden realizar en bases de datos de prueba (que se borran después de la prueba) y en la base de datos permanente (cada una tiene una base de datos permanente, servidor de producción y servidor de desarrollo). Y una cosa importante: me encuentro moviendo muchos códigos comunes de los archivos de prueba a los archivos de clase. Entonces las clases también obtienen habilidades que son solo para pruebas.Me gusta esto hasta ahora, me siento limpio. No estoy (todavía) creando una biblioteca para las pruebas que se comparte entre las 2 interfaces de prueba, este código ha ido al archivo de clases del objeto que se está tratando por el momento.

Tenga en cuenta que mis comentarios a continuación están firmados con "user89021" pero soy yo, karlthorwald. No puedo hacer nada al respecto.

Respuesta

4

usted debe separar la base de datos de pruebas relacionadas con las pruebas de unidad "puros".
El costo de tener dos ensamblajes diferentes es muy bajo teniendo en cuenta los beneficios: tiene un conjunto de pruebas rápidas, sin entorno establecido que puede ejecutar en cualquier máquina y una serie más lenta que prueba la integridad de la base de datos que puede ejecutarse solo lugares (por ejemplo, servidor de compilación).

Otra ventaja es que puede tener dos procesos de compilación (rápidos y nocturnos) que ejecutan diferentes conjuntos de pruebas.

Para evitar la duplicación de código, puede crear otro ensamblado con los métodos/acciones comunes que ambas suites de prueba necesitan. No se preocupe demasiado por duplicar las pruebas reales porque está probando diferentes cosas (ya sea lógica o de base de datos) por lo que tarde o temprano sus pruebas serán bastante diferentes dependiendo de lo que intente probar.

4

Su enfoque para separarlos es bueno.

Su preocupación por la duplicación de código es 100% válida.

La solución es bastante simple: abstraer la funcionalidad común entre las pruebas, por ej. "RunTest", "AnalyzeResult", "ConnectToDB" - en una biblioteca común (no especificó qué idioma, pero supongo que tiene un concepto de biblioteca) al que se le pueden pasar detalles de configuración, como a qué base de datos conectarse.

Luego use esa biblioteca independientemente del controlador de prueba de la unidad y el controlador de prueba de integridad que, si es hábil/afortunado, podría tener muy poco código aparte de la configuración (por ejemplo, a qué base de datos conectarse, cómo informar resultados y qué pruebas ejecutar).

Del mismo modo, si es necesario, entradas comunes/conjuntos de datos se pueden colocar en el directorio común

+0

Gracias. No especifico porque quiero evitar que mi pregunta se etiquete con idiomas. Bibliotecas, Objetos, herencia, todo lo posible aquí. – user89021

+0

No fue fácil aceptar una respuesta porque ambos son muy buenos y me ayudaron. Muchas gracias. – user89021

0

Una respuesta más. Tienes dos tipos de pruebas. Lo que me gustaría hacer es abordar las pruebas de integridad. Lo que puede querer hacer es incluir las pruebas de integridad como una función del código de producción . IOW, tiene la integridad como parte del sistema.

Usted mencionó que la duplicación es un problema y que está refactorizando para eliminar la duplicación. El código de código refactorizado tiene pruebas de desarrollo?

La monitorización del sistema puede ser un código de producción. Entonces, cualquiera que sea el código que escriba se convierte en parte del sistema.

Lo bueno de esto es que evoluciona su código a través de sus pruebas de desarrollo.

+0

Gracias. Su respuesta realmente me ayudó, especialmente "el monitoreo del sistema puede ser parte de la producción". ¡Mi desarrollo ha mejorado mucho con estas 3 respuestas! – user89021

Cuestiones relacionadas