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

Question

que tienen un proyecto que estoy construyendo con Maven que utiliza Hibernate (y primavera) para recuperar datos de una base de datos, etc.

Mis "pruebas" para los DAOs en mi proyecto se extienden primavera de AbstractTransactionalDataSourceSpringContextTests de modo que una fuente de datos puede ser conectado a mi clase bajo prueba para poder ejecutar realmente la consulta/Hibernar la lógica, para buscar datos, etc.

En varios otros proyectos he usado estos tipos de pruebas en concierto con una base de datos HSQL (en -memory o apuntado 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.

Tengo curiosidad acerca de la mejor manera de organizar estas pruebas, que son realmente 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 Failsafe plugin (o una segunda instancia de Surefire) y vincularlo a la fase integration-test, y que también puedo vincular la lógica personalizada de inicio o apagado (como para iniciar/detener la instancia de HSQL) a pre-integration-test o post-integration-test. Pero, ¿este es realmente el mejor método?

Así que mi pregunta básicamente es: ¿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:

• pruebas de unidad separada de las pruebas de integración, pruebas de unidad por lo que sólo se ejecutan durante la fase de test
• La capacidad de unir la lógica de inicio personalizada/apagado para pre-integration-test y post-integration-test
• que los informes de las pruebas de integración-fusionada/presentadas con la prueba de la unidad de éxito seguro informa

Answer 1

Hay este codehaus page 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 las pruebas de integración en src/ITest/Java En la fase previa a la integración de la prueba:

• claros destinatarios/prueba-clases
• Usar el objetivo build-helper-maven-plugin 's complemento prueba de código de Agregue la ubicación de origen más barata
• Utilice un Mojo personalizado para eliminar src/test/java de la configuración para que las pruebas de unidad no se compilen nuevamente (realmente no me gusta, pero es necesario para mantener la separación de unidad e integración pruebas).
• el compilador se utilice-plugin para compilar las pruebas de integración

A continuación, en la fase de pruebas de integración, utilice el éxito seguro-plugin para ejecutar las pruebas.

Por último, ata los objetivos de ordenación a la fase posterior a la prueba de integración (aunque normalmente no son necesarios, ya que puedes utilizar el desmantelamiento de prueba() para ponerlo en orden).

que aún no han encontrado una manera de combinar los resultados de la prueba como la fase de presentación de informes ha pasado, pero tienden a ver las pruebas de integración, como algo adicional, por lo que el tiempo que pasan en 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 utilizar un objetivo de embarcadero. Esto le da un control mucho más fino sobre las pruebas. Puede obtener más detalles en this answer y en los blogs a los que se hace referencia.

Answer 2

This good blog post sugiere tres opciones;

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

2) Diferentes directorios de origen

3) Diferentes patrones de nombre de archivo

estoy aún a prueba las tres, por lo que no puede ofrecer una opinión en el que estoy a favor.

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. Anotar las clases que desea dividir
3. plugins de Maven Configurar.

Aquí se ofrece un ejemplo completo. https://stackoverflow.com/a/10381662/1365383

Answer 4

Prefiero la segunda opción, diferentes directorios fuente, pero me pareció bastante molesto tener que terminar con IT las pruebas de integración o excluir 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 puedo reemplazar ambas variables en diferentes perfiles para la integración y la aceptación de pruebas:

<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> 
..... 
..... 
.....