maven - multi - spring boot unit testing tutorial

Prueba de integración de extremo a extremo para múltiples aplicaciones de arranque por resorte bajo Maven (2)

¿Cuál es la forma recomendada de ejecutar una prueba de integración de extremo a extremo para varias aplicaciones de arranque Spring en la fase de verificación de la compilación de Maven ?

Básicamente, tengo un proyecto de varios módulos de Maven en el que varios módulos son aplicaciones de arranque por resorte separadas. Estas aplicaciones separadas tienen su propia configuración para orígenes de datos, flujos de integración con colas JMS , etc. Por ejemplo, la aplicación A sondeará una base de datos para detectar un evento, y cuando eso ocurre, produce un archivo JSON de datos y coloca un mensaje en un Cola JMS . La aplicación B está sondeando la cola JMS , por lo que recoge el mensaje, lee el archivo, realiza un procesamiento utilizando otra base de datos y coloca un mensaje en una cola diferente. La aplicación C recogerá ese mensaje, etc., etc.

He configurado pruebas de integración para las aplicaciones individuales; estos se ejecutan bajo el complemento a prueba de fallos de Maven. Sin embargo, me gustaría probar la integración de todo el sistema, de principio a fin, bajo Maven. He configurado un módulo separado en el proyecto dedicado a esta tarea, por lo que me gustaría que la fase de compilación de verificación de este módulo realice las pruebas de extremo a extremo utilizando los otros módulos dependientes.

¿Hay una forma mejor práctica de hacer esto? Veo 3 formas potenciales:

Cargue la configuración de cada aplicación en el mismo contexto de la aplicación. Sin embargo, debido a los múltiples orígenes de datos, etc., esto crea conflictos, por lo que estos orígenes de datos tendrían que configurarse manualmente solo para habilitar las pruebas de integración de extremo a extremo, por lo que me parece incorrecto.
Inicie cada aplicación como un proceso separado: ¿cómo realizar un seguimiento adecuado de ellas y asegurarse de que se cierren si el módulo de prueba se detiene / se bloquea / etc?
¿Hay una manera de cargar fácilmente aplicaciones de arranque por resorte separadas, cada una con su propio contexto de configuración, en el mismo proceso? Esta parece ser la opción más sensata. ¿Hay alguna consideración con respecto al complemento Maven build / failafe?

Muy buena pregunta! Yo solo estaría interesado en lo que otras personas responden. Voy a compartir mi opinion

En mi entendimiento, en primer lugar, debes saber qué es exactamente lo que quieres probar. Las pruebas de integración deberían funcionar con una aplicación de al menos una parte de ella y garantizar que el componente que ha desarrollado funcione correctamente en un entorno semi-real. Parece que ya lo has hecho.

Ahora, con respecto a las pruebas del sistema (distingo intencionalmente entre la integración y las pruebas del sistema). Estos deberían "imitar" a los muchachos de control de calidad :) Entonces, tratan un sistema como una caja negra. No pueden invocar ninguna API interna y ejecutar flujos reales. Las pruebas de extremo a extremo IMO caen en esta categoría.

En este caso, le gustaría compararlos con el sistema implementado como en producción, con el classpath como en producción.

Así que realmente no creo en la opción 1 como tú.

Con respecto a la opción 3, no estoy seguro de que también sea una buena solución. Incluso si ejecutas tus cosas con diferentes contextos de aplicaciones (no sé mucho Spring Boot, así que técnicamente no puedo hacer comentarios al respecto), según tengo entendido, compartirán la misma ruta de clase en tiempo de ejecución, por lo que probablemente corres el riesgo de consiga un choque entre sus terceros (aunque sé que Spring Boot define muchas versiones de tarros por sí mismo, ya sabe a qué me refiero), especialmente cuando actualiza solo un módulo y probablemente cambia las dependencias. Por lo tanto, no sabe realmente qué se ejecuta exactamente en la memoria cuando ejecuta este enfoque.

Por lo tanto, para las pruebas de extremo a extremo , optaría por la opción 2. Con respecto a la sincronización, probablemente la opción sería implementar cierta lógica en el nivel de la aplicación junto con el seguimiento del estado del proceso en el nivel del sistema operativo. Otro punto que me gustaría comentar es que, en general, las pruebas de extremo a extremo siguen siendo pruebas funcionales (verifican el comportamiento funcional del sistema), por lo que en general no debería verificar los bloqueos del sistema en cada prueba. Si verifica la falla del sistema para cada flujo, estas pruebas serán demasiado lentas. Por supuesto, puede mantener un conjunto de pruebas relativamente pequeño para verificar casos de esquina como tales.

Espero que esto ayude

Solo para dar seguimiento y decir lo que terminé haciendo (que sigue funcionando bien):

jgitflow los siguientes perfiles de Maven en mi módulo de prueba: "predeterminado" para omitir las pruebas de manera predeterminada (usamos el complemento jgitflow por lo que solo queremos que se ejecuten pruebas de extremo a extremo cuando se solicitan explícitamente), "standalone-e2e" para extremo a extremo pruebas que no requieren recursos externos, como bases de datos (dirigidas a desarrolladores que desean realizar una prueba completa de extremo a extremo) y "e2e integrado" para pruebas de extremo a extremo que utilizan bases de datos reales, etc. (que pueden activarse como parte de CI). Los perfiles de resorte (activados por el perfil correspondiente de Maven) controlan la configuración de los componentes individuales.
Para standalone-e2e, los complementos relevantes como activemq-maven-plugin , hsqldb-maven-plugin etc. lanzan (y luego cierran) los recursos como parte de la prueba de extremo a extremo, que se ejecuta en los puertos reservados con build-helper-maven-plugin process-exec-maven-plugin se utiliza para iniciar todos los componentes que se van a probar en la fase de prueba de integración previa (como aplicaciones estándar de Spring Boot), y se encarga de apagarlos automáticamente en la prueba de integración posterior. fase. La configuración de Spring y las dependencias específicas de prueba de Maven se ocupan de otros recursos, como un servidor FTP falso . Una vez que se ejecutan todos los recursos y componentes, el propio código de prueba luego llena la base de datos y el sistema de archivos según sea necesario y activa los flujos (y espera las respuestas correspondientes, etc.) utilizando JMS.
El perfil integrado de e2e es casi idéntico, pero utiliza recursos externos "reales" (en nuestro caso, colas de Amazon SQS, base de datos MySQL, etc.) configurados en las propiedades de Spring asociadas.
Todos los archivos necesarios para y generados por las pruebas (por ejemplo, archivos de datos, archivos HSQLDB, archivos de registro, etc.) se crean bajo el directorio de compilación "objetivo", por lo que es fácil inspeccionar esta área para ver qué sucedió durante la prueba, y también permitir "mvn limpio" para borrar todo.

Espero que sea útil: ciertamente fue refrescante descubrir que, independientemente de lo que tenía que hacer, ¡existía un complemento de Maven para cuidarlo!