Pregunta

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

Pero la parte complicada es: Hudson despliega e inicia un 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 la socket, las variables de entorno, la entrega de fallos de inicio del servidor, etc. Tenemos que configurar y derribar estas cosas correctamente cada vez, es difícilcosa.Peor aún, las pruebas de integración pueden romper la prueba de integración fácilmente.

¿Cree que si la prueba de integración debe incluirse en la integración continua (CI)?¿Puede ser manualmente?¿O simplificar la prueba de integración?

¿Fue útil?

Solución

El nombre continuo integración dice mucho.¿Qué mejor lugar para realizar pruebas de integración que donde ya estás integrando? Por supuesto, no debe ser el único lugar que tienen lugar esas pruebas, al desarrollarlo, debe intentar asegurarse de que no rompa las cosas después de todo, no solo que sus cambios funcionan 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 las personas o las etapas a las que se restringe las pruebas son contraproducentes.

Otros consejos

¿Cree que si se debe incluir la prueba de integración en la integración continua (CI)?

Si tiene pruebas de integración que están pasando, y no exige que alguien permanezca allí y presione los botones, entonces sí, debe agregarlos al sistema CI.

Pero, dado que las pruebas de integración pueden tener mucho tiempo para ejecutar, 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 está preguntando. 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 de compilación completo para implementar rápidamente. Esto requiere que los desarrolladores obtengan una respuesta rápida proporcionada por el proceso de integración continua. Así que él define las etapas que la construcción debe pasar por :

  1. una construcción de confirmación
  2. Pruebas exhaustivas
  3. despliegue
  4. La construcción de confirmación no debe demorar más de 10 minutos que afirma, debido a la rápida retroalimentación para los desarrolladores.

    Aquí es cómo veo las cosas: En el primer paso, busca el último compromiso y construya. Si esto es exitoso, ejecuta sus pruebas de unidad para averiguar si sus clases / grupos de clase están funcionando según lo definido y esperado.

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

    Después de asegurarse de que las unidades estén trabajando e interactuando según sea necesario, generalmente desea obtener información sobre la cobertura de prueba (solo probar un pequeño subsistema generalmente no es suficiente) y hacer que los artefactos analizados estén disponibles para las pruebas funcionales / QA / Despliegue (lea: Pruebas exhaustivas) Si cree que pruebas cubren suficiente de su programa. En ese momento, proporciona un entorno de prueba que refleja el entorno de producción que está dirigido y ejecutando pruebas que involucran una base de datos real, archivos reales, pares reales de redes, etc.

    Al final, las pruebas de integración son sobre los cambios de código. Desea asegurarse de que los cambios que realicen no estén rompiendo el sistema actual, lo que significa que se integran bien. Para averiguar si lo son, debe asegurarse de que se comporten correctamente en sí mismos, si interactúan correctamente con sus dependencias, y si se probaron en absoluto. Puede estar tranquilo seguro sobre su sistema después de que haya pasado 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 apague en las pruebas de integración. La construcción de confirmación más probable es más rápida que el QA;)

Licenciado bajo: CC-BY-SA con atribución
scroll top