¿Cuál es la forma adecuada de probar código que utiliza consultas específicas de MySQL internamente?

Question

Estoy recopilando datos y almacenando estos datos en una base de datos MySQL utilizando Java. Además, uso Maven para construir el proyecto, TestNG como marco de prueba y Spring-Jdbc para acceder a la base de datos. Implementé una capa DAO que encapsula el acceso a la base de datos. Además de agregar datos usando las clases DAO, quiero ejecutar algunas consultas que agregan los datos y almacenan los resultados en algunas otras tablas (como las vistas materializadas).

Ahora, me gustaría escribir algunas cajas de prueba que comprueban si las clases DAO funcionan como deberían. Por lo tanto, pensé en usar una base de datos en memoria que se completará con algunos datos de prueba. Desde También estoy usando consultas SQL específicas de MySQL para la agregación de datos, fui con algunos problemas:

1. En primer lugar, he pensado en el simple uso de la funcionalidad de base de datos integrada proporcionada por el resorte en JDBC para crear instancias de una base de datos integrada . Decidí usar la implementación de H2. Ahí me encontré con problemas debido a las consultas de agregación, que utilizan contenido específico de MySQL (por ejemplo, funciones de manipulación de tiempo como DATE()). Otra desventaja de este enfoque es que necesito mantener dos archivos ddl: el archivo ddl real que define las tablas en MySQL (aquí defino la codificación y agrego comentarios a las tablas y columnas, ambas características son específicas de MySQL); y el archivo ddl de prueba que define las mismas tablas pero sin comentarios, etc. ya que H2 no admite comentarios.
2. He encontrado una descripción para usar MySQL como una base de datos incrustada que puedo usar dentro de los casos de prueba (http://literatitech.blogspot.de/2011/04/embedded-mysql-server-for-junit-testing .html). Eso sonaba realmente prometedor para mí. Lamentablemente, no funcionó: se produjo una excepción MissingResourceExcpetion "Resource '5-0-21/Linux-amd64/mysqld' not found". Parece que el controlador no puede encontrar el daemon de la base de datos en mi máquina local. Pero no sé qué tengo que buscar para encontrar una solución para ese problema.

Ahora, estoy un poco atascado y me pregunto si debería haber creado la arquitectura de manera diferente. ¿Alguien tiene algunos consejos sobre cómo debo configurar un sistema apropiado? Tengo otras dos opciones en mente:

1. En lugar de utilizar una base de datos integrada, voy a ir con una instancia de MySQL nativa y la configuración de una base de datos que sólo se utiliza para los casos de prueba. Esta opción suena lenta. De hecho, me gustaría configurar un servidor de CI más adelante y pensé que usar una base de datos integrada sería más apropiado ya que la prueba se ejecuta más rápido.
2. Borro todo el material específico de MySQL de las consultas SQL y uso H2 como una base de datos incrustada para la prueba. Si esta opción es la correcta, necesitaría encontrar otra manera de probar las consultas SQL que agregan los datos en vistas materializadas.
3. ¿O hay una tercera opción que no tengo en mente?

Agradecería cualquier pista.

Gracias, XComp

Answer 1

Si no es posible obtener la base de datos MySQL en memoria a trabajar sugiere emplear la base de datos H2 para el "simple" pruebas y una instancia de MySQL dedicado a probar mysql- consultas específicas.

Además, las pruebas para la base de datos real de MySQL pueden configurarse como pruebas de integración en un perfil de experto independiente para que no formen parte de la construcción de maven normal. En el servidor de CI puede crear un trabajo adicional que ejecute las pruebas de MySQL periódicamente, p. diariamente o cada pocas horas.Con esta configuración, puede mantener y probar las consultas específicas de su producto, mientras que su compilación normal no se ralentizará. También puede ejecutar una compilación normal incluso si la base de datos de prueba no está disponible.

Hay un buen complemento maven para pruebas de integración llamado maven-failsafe-plugin. Proporciona pasos de prueba previos y posteriores a la integración que se pueden usar para configurar los datos de prueba antes de las pruebas y para limpiar la base de datos después de las pruebas.

Answer 2

He creado el plugin Maven exactamente para este propósito: jcabi-mysql-maven-plugin. Inicia un servidor MySQL local en la fase pre-integration-test y lo apaga en post-integration-test.