java - tipos - ¿Mejores prácticas para las pruebas de integración con Maven?

que son las pruebas unitarias de software

Question

Tengo un proyecto que estoy desarrollando con Maven que usa Hibernate (y Spring) para recuperar datos de una base de datos, etc.

Mis "pruebas" para los DAO en mi proyecto amplían Spring''s AbstractTransactionalDataSourceSpringContextTests para que un DataSource se pueda conectar a mi clase bajo prueba para poder ejecutar realmente la lógica de consulta / Hibernación, para captar datos, etc.

En varios otros proyectos, he usado estos tipos de pruebas en concierto con una base de datos HSQL (ya sea en memoria o apuntando a un archivo) para poder probar eficientemente la lógica de consulta de la base de datos real sin depender de una base de datos externa. Esto funciona muy bien, ya que evita cualquier dependencia externa y el "estado" de la base de datos antes de ejecutar las pruebas (cada una de las cuales está envuelta en una transacción que se retrotrae) está bien definida.

Sin embargo, tengo curiosidad acerca de la mejor manera de organizar estas pruebas, que realmente son un sabor flojo de pruebas de integración, con Maven. Se siente un poco sucio mantener estas pruebas en src/test/java , pero por lo que he leído no parece haber una estrategia o práctica consistente para organizar pruebas de integración con Maven.

Por lo que he leído hasta ahora, parece que puedo usar el complemento Failsafe (o una segunda instancia de Surefire) y vincularlo a la fase de integration-test , y que también puedo vincular la lógica personalizada de inicio o cierre (tal en cuanto a iniciar / detener la instancia de HSQL) a pre-integration-test o pre-integration-test post-integration-test . Pero, ¿este es realmente el mejor método?

Entonces mi pregunta es básicamente: ¿cuál es la mejor práctica generalmente aceptada para organizar esto con Maven? Tengo problemas para encontrar cualquier tipo de respuesta consistente en la documentación.

Lo que me gustaría es:

• Separar las pruebas unitarias de las pruebas de integración, por lo que solo se ejecutan pruebas unitarias durante la fase de test
• La capacidad de vincular la lógica personalizada de inicio / apagado a pre-integration-test post-integration-test
• Haga que los informes de las pruebas de integración se fusionen / presenten con la unidad de prueba de los informes Surefire

Answer 1

Esta es la página de codehaus con algunas pautas. Descubrí que el plugin de failsafe es un hack, y hace que ejecutar las pruebas unitarias en Eclipse sea un poco complicado. Hago ampliamente lo que describes.

Definir pruebas de integración en src / itest / java En la fase de prueba previa a la integración:

• Claro objetivo / clases de prueba
• Utilice el objetivo add-test-source de build-helper-maven-plugin para agregar la ubicación de origen más adecuada
• Use un Mojo personalizado para eliminar src / test / java de la configuración para que las pruebas de la unidad no se vuelvan a compilar (realmente no me gusta, pero es necesario para mantener la separación de la unidad y las pruebas de integración).
• Use el compilador-complemento para compilar las pruebas de integración

Luego, en la fase de prueba de integración, use el complemento surefire para ejecutar las pruebas.

Finalmente, una los objetivos de ordenación a la fase posterior a la prueba de integración (aunque normalmente no son necesarios, ya que puede utilizar la eliminación de prueba () para poner en orden).

Todavía no he encontrado una forma de fusionar los resultados de la prueba a medida que la fase de generación de informes ha pasado, pero tiendo a ver las pruebas de integración como una ventaja adicional, por lo que siempre que pasen el informe no es tan importante.

Actualización: creo que vale la pena señalar que puede ejecutar Jetty desde sus pruebas de integración en lugar de usar un objetivo de embarcadero. Esto le da un control mucho más fino sobre las pruebas. Puede obtener más detalles de esta respuesta y de los blogs a los que se hace referencia.

Answer 2

Prefiero la segunda opción, diferentes directorios fuente, pero me pareció bastante molesto tener que terminar con IT las pruebas de integración o excluyendo paquetes.

Para evitar esto, he terminado con esta configuración:

<properties>
<testSource>src/test/java</testSource>
<testSourceResource>src/test/resources</testSourceResource>
</properties>
<build>
<testSourceDirectory>${testSource}</testSourceDirectory>
<testResources>
<testResource>
<directory>${testSourceResource}</directory>
</testResource>
</testResources>
.....
.....

y luego anulo ambas variables en diferentes perfiles para la prueba de integración y aceptación:

<profiles>
<profile>
<id>acceptance-tests</id>
<properties>
<testSource>src/acceptance-test/java</testSource>
<testSourceResource>src/acceptance-test/resources</testSourceResource>
</properties>
</profile>
<profile>
<id>integration-tests</id>
<properties>
<testSource>src/integration-test/java</testSource>
<testSourceResource>src/integration-test/resources</testSourceResource>
</properties>
</profile>
.....
.....
.....

Answer 3

Una forma muy simple de hacer esto es usar categorías JUnit.

Luego puede ejecutar fácilmente algunas pruebas durante la fase de prueba y otra durante la fase de prueba de integración.

Toma minutos y solo requiere 3 pasos.

1. Definir una interfaz de marcador
2. Anota las clases que deseas dividir
3. Configurar los complementos Maven.

Un ejemplo completo se da aquí. https://.com/a/10381662/1365383

Answer 4

Esta buena publicación de blog sugiere tres opciones;

1) Módulo separado para pruebas de integración

2) diferentes directorios fuente

3) Diferentes patrones de nombre de archivo

Todavía tengo que probar los tres, por lo que no puedo ofrecer una opinión que yo prefiera.