¿Hay una manera de prevenir la prueba Maven desde la reconstrucción de la base de datos?

Question

Me han pedido recientemente para, efectivamente, vender mi departamento en la unidad de pruebas. No puedo decir lo emocionado que esto me hace, pero tengo una preocupación. Estamos utilizando JUnit con Spring y Maven, y esto significa que cada vez que se llama mvn test, se reconstruirá la base de datos. Obviamente, no podemos integrar que con nuestro servidor de producción - que mataría a datos valiosos.

¿Cómo puedo evitar la reconstrucción sin decirle a Maven para omitir la prueba?

Lo mejor que pude averiguar fue asignar la secuencia de comandos para operar en una base de datos de prueba (saltos de línea añaden para facilitar la lectura):

mvn test 
   -Ddbunit.schema=<database>test 
   -Djdbc.url=jdbc:mysql://localhost/<database>test?
        createDatabaseIfNotExist=true&amp;
        useUnicode=true&amp;characterEncoding=utf-8 

No puedo evitar pensar que debe haber una mejor manera.

Estoy especialmente interesado en aprender si hay una manera fácil de decir Maven solamente para ejecutar pruebas en las clases particulares sin la construcción de cualquier otra cosa? mvn -Dtest=<test-name> test todavía vuelve a generar la base de datos.

======= ======= actualización

Un poco de huevo en mi cara aquí. No me daba cuenta de que yo estaba usando la misma variable en dos lugares, lo que significa que el POM se utiliza una variable "skip.test" tanto para la reconstrucción de la base de datos y para ejecutar las pruebas ...

Answer 1

Actualización: supongo que DBUnit hace la reconstrucción de la base de datos, ya que se dijo que lo hiciera en el método de configuración de la prueba. Si cambia el método de configuración, se puede eliminar la base de datos a reconstruir. Por supuesto, debe hacerlo de manera que se obtiene el restablecimiento DB cuando lo necesite, y omitirlo cuando no lo hace. Mi primera apuesta sería utilizar una propiedad del sistema para controlar esto. Puede establecer la propiedad en la línea de comandos de la misma manera que ya lo hacen con jdbc.url et al. Luego, en el método de configuración agrega una if para la prueba de que la propiedad y hacer el reinicio DB si se establece.

Una base de datos de prueba, completamente separado de su producción de DB es sin duda la mejor opción si se puede tener. Incluso puede utilizar, por ejemplo, Derby , una DB en memoria que puede funcionar incrustado dentro de la JVM. Pero en caso de que absolutamente no se puede tener una base de datos separada, utilice al menos un esquema de prueba independiente dentro de esa base de datos.

En este escenario le recomiendo que ponga sus parámetros de conexión de base de datos en los perfiles dentro de su pom, siendo la base de datos de prueba por defecto, y un perfil independiente para contener la configuración de producción. De esta manera nunca puede suceder que accidentalmente ejecutar las pruebas en contra de la base de datos de producción.

En general, sin embargo, también es importante entender que las pruebas se ejecutan contra una base de datos no son realmente pruebas de unidad en el sentido estricto, más pruebas de integración. Si usted tiene un conjunto existente de este tipo de pruebas, bien, utilizarlos como todo lo que pueda. Sin embargo, usted debe tratar de avanzar hacia la adición de más pruebas de unidad real, lo que prueba sólo una porción pequeña y aislada de su código a la vez (un método o una clase de como máximo), lo ideal es autónomo (no necesitan DB, archivos de red, configuración, etc. ) para que puedan correr rápido - este es un punto muy importante. Si usted tiene pruebas de la unidad 5000 y cada uno sólo 5 segundos para correr, que asciende hasta casi 7 horas, por lo que, obviamente, no se quedará muy a menudo. Si una prueba tarda sólo 5 milisegundos, se obtienen los resultados en menos de medio minuto, por lo que puede permitirse el lujo de ejecutar todas las pruebas antes de comprometer su último cambio - muchas veces al día. Eso hace una gran diferencia en la velocidad de la retroalimentación que recibe de las pruebas.

Espero que esto ayude.

Answer 2

  

Estamos utilizando JUnit con Spring y Maven, y esto significa que cada vez que se llama mvn test, se reconstruirá la base de datos.

Maven no hace nada con bases de datos por sí mismo, su código hace. En cualquier caso, es muy inusual para ejecutar las pruebas (que no son pruebas unitarias) contra una base de datos de producción.

  

¿Cómo puedo evitar la reconstrucción sin decirle a Maven para omitir la prueba?

Es difícil de decir sin más detalles (que no está mostrando nada) pero los perfiles de podría ser un camino a seguir.

Answer 3

Las pruebas unitarias, por definición, sólo funcionan en un único componente en el sistema. No deberías estar intentando escribir pruebas unitarias que se integran con los servicios externos (web, DB, etc.). La solución Tengo que esto es utilizar un buen marco de burla a apagar el comportamiento de cualquier dependencia de sus componentes tienen. Esto anima a los buenos API de interfaz como la mayoría de los marcos burlones funcionan mejor con interfaces simples. Sería mejor para crear una interfaz de patrón de repositorio para cualquier interacción con su base de datos y luego burlarse de la impl cualquier momento que se está probando una clase que interactúa con él. A continuación, puede probar funcionalmente su impl repositorio separado. Esto también tiene la ventaja añadida de mantener las pruebas unitarias suficientemente rápido como para seguir siendo parte de su CI para que su ciclo de regeneración es tan rápido como sea posible.