¿Debería incluirse la prueba de integración en la integración continua (CI)?

Supongamos que estamos desarrollando una aplicación web, y Hudson realiza trabajos típicos como compilar, pruebas unitarias y análisis de código estático.

Pero la parte difícil es: Hudson implementa e inicia el servidor de aplicaciones para realizar pruebas de integración , una vez que se realizan los trabajos anteriores.

Eso significa algunas cosas difíciles, como la conexión de la base de datos, la conexión de la aplicación de la tercera parte, la escucha del puerto de socket, las variables de entorno, la entrega de fallos de inicio del servidor, etc. Tenemos que configurar y desmontar estas cosas correctamente cada vez, es algo difícil. Peor aún, las pruebas de integración pueden romper la prueba de integración fácilmente.

¿Crees que la prueba de integración debería incluirse en la integración continua (CI)? ¿Se puede hacer manualmente? ¿O simplificar la prueba de integración?

el nombre Integración continua dice mucho. ¿Qué mejor lugar para hacer pruebas de integración que donde ya se está integrando?
Por supuesto, no debería ser el único lugar donde se llevan a cabo esas pruebas, cuando se desarrolle, debe intentar asegurarse de no romper las cosas después de todo, no solo de que sus cambios funcionen de forma aislada.
Al final, es responsabilidad de cada miembro del equipo que las cosas no se rompan, tratando de culpar y definir rígidamente a las personas o etapas a las que se restringe la prueba son contraproducentes.

¿Crees que la prueba de integración debería incluirse en la integración continua (CI)?

Si tiene pruebas de integración que están pasando y no requiere que alguien se pare allí y presione los botones, entonces sí, debe agregarlas al sistema CI.

Pero, dado que las pruebas de integración pueden tardar mucho en ejecutarse, debe limitar la frecuencia con la que se ejecutan. Se pueden ejecutar durante una noche, cuando el servidor CI está inactivo.

Para responder primero a su pregunta: Sí, definitivamente son parte de la Integración continua si me lo pregunta. Pero creo que debemos aclarar qué son las pruebas de integración.

Martin Fowler estaba hablando de la entrega continua como una forma de automatizar el proceso completo de construcción para implementar rápidamente. Esto requiere que los desarrolladores obtengan comentarios rápidos proporcionados por el proceso de integración continua. Entonces, define las etapas por las que debe pasar la construcción :

1. una compilación de compromiso
2. pruebas exhaustivas
3. despliegue

La compilación de confirmación no debería llevar más de 10 minutos, afirma, debido a la rápida respuesta de los desarrolladores.

Así es como veo las cosas: en el primer paso, obtenga la última confirmación y compílela. Si esto es exitoso, ejecuta sus pruebas unitarias para averiguar si sus clases / grupos de clase funcionan según lo definido y esperado.

Cuando esto tiene éxito, llega a la parte de prueba de integración. Aquí puede probar la interacción de las unidades probadas con éxito. Esto implica alimentar las unidades con entrada y observar su estado / interacción / salida. Recuerde que todavía estamos en la compilación de confirmación, por lo que queremos que esto también sea rápido. Por lo tanto, las interacciones con el sistema de archivos, una base de datos, los pares de la red y similares deben tropezarse para una ejecución rápida. Martin Fowler también sugiere el uso de bases de datos en memoria si las necesita, solo para mantener la ejecución en el servidor CI rápidamente.

Después de asegurarse de que las unidades funcionan e interactúan según sea necesario, generalmente desea obtener información sobre la cobertura de prueba (simplemente probar un subsistema pequeño generalmente no es suficiente) y hacer que los artefactos probados estén disponibles para pruebas funcionales / QA / implementación ( lea: pruebas exhaustivas) si cree que las pruebas cubren suficiente de su programa. En ese momento, aprovisiona un entorno de prueba que refleja el entorno de producción al que se dirige y ejecuta pruebas que involucran una base de datos real, archivos reales, pares de red reales, etc.

Al final, las pruebas de integración son sobre cambios de código. Desea asegurarse de que los cambios que realizó no rompan el sistema actual, lo que significa que se integran bien. Para saber si lo son, debe asegurarse de que se comporten correctamente en sí mismos, luego si interactúan correctamente con sus dependencias y si se probaron en absoluto. Puede estar seguro de su sistema después de pasar todas esas pruebas.

Si las etapas posteriores encuentran algún problema con su programa (como cuando su base de datos devuelve un cierto valor, su conexión de red se detendrá), debe intentar que estas pruebas se apaguen en las pruebas de integración. La compilación de confirmación probablemente sea más rápida que el control de calidad