JUnit para código de base de datos

Question

He estado intentando implementar pruebas unitarias y actualmente tengo un código que hace lo siguiente:

1. consulta la base de datos externa, cargándose en una tabla de alimentación
2. consulta una vista, que es un delta de mis tablas de alimentación y datos, actualizando la tabla de datos para que coincida con la tabla de alimentación

Mi estrategia de prueba unitaria es esta:

Tengo una base de datos de prueba que puedo manipular libremente.

1. en setUP(), cargue algunos datos en mi base de datos de prueba
2. ejecutar mi código, utilizando mi base de datos de prueba como fuente
3. inspeccionar la tabla de datos, comprobando los conteos y la existencia/no existencia de ciertos registros
4. borrar la base de datos de prueba, cargar un conjunto diferente de datos
5. ejecutar el código nuevamente
6. inspeccionar la tabla de datos nuevamente

Obviamente, tengo los conjuntos de datos que cargo en la base de datos de origen configurados de manera que sé que ciertos registros deben agregarse, eliminarse, actualizarse, etc.

¿Parece que esto es un poco engorroso y debería haber una manera más fácil?¿alguna sugerencia?

Answer 1

¿Es su intención probar la vista que genera los deltas, o probar que su código agrega, elimina y actualiza correctamente en respuesta a la vista?

Si desea probar la vista, puede utilizar una herramienta como Unidad DB para completar sus tablas de datos y feeds con diversos datos cuyo delta haya calculado manualmente.Luego, para cada prueba, verificaría que la vista devuelva un conjunto coincidente.

Si desea probar cómo responde su código a las diferencias detectadas por la vista, intentaría abstraer el acceso a la base de datos.Me imagino un método java al que se le puede pasar un conjunto de resultados (o una lista de POJO/DTO) y devuelve una lista de matrices de objetos de parámetros (nuevamente, o POJO) que se agregarán.Otros métodos analizarían la lista de diferencias en busca de elementos que se eliminarán y actualizarán.Luego, podría crear un conjunto de resultados simulado o pojo, pasarlos a su código y verificar que se devuelvan los parámetros correctos.Todo sin tocar una base de datos.

Creo que la clave es dividir el proceso en partes y probar cada una de ellas de la forma más independiente posible.

Answer 2

Unidad Db satisfará sus necesidades.Una cosa a tener en cuenta es que han pasado a utilizar SLF4J como fachada de registro en lugar de JCL.Puede configurar SLF4J para reenviar el registro a JCL, pero tenga en cuenta que si está utilizando Maven DbUnit apesta en su proveedor de registro Nop de forma predeterminada, por lo que tendrá que usar una exclusión. blogueado sobre este conflicto recientemente.

Answer 3

Utilizo DbUnit, pero también trabajo muy duro para no tener que realizar pruebas con la base de datos.Las pruebas que van contra la base de datos solo deben existir con el fin de probar la interfaz de la base de datos.Entonces tengo Mock Db Connections y puedo configurar los datos para usarlos en el resto de mis pruebas.

Answer 4

Además del DBUnit ya sugerido, es posible que desees investigar unidades.Utiliza DBUnit, pero proporciona más que eso (citando del sitio):

• Mantenimiento automático de bases de datos, con soporte para scripts incrementales, repetibles y de procesamiento posterior
• Deshabilite automáticamente las restricciones y establezca secuencias en un valor mínimo
• Soporte para Oracle, Hsqldb, MySql, DB2, Postgresql, MsSql y Derby
• Simplifique la configuración de la conexión de la base de datos de prueba
• Inserción simple de datos de prueba con DBUnit * Ejecutar pruebas en una transacción
• JPA Entity Manager Creation and Inyection para Hibernate, Toplink y * Hibernate SessionFactory y sesión
• Pruebe automáticamente la asignación de entidades JPA / objetos mapeados de hibernación con la base de datos

Answer 5

Si está utilizando Maven, una opción es utilizar el complemento-sql-maven.Le permite ejecutar scripts de inicialización/población de bases de datos durante el ciclo de compilación de Maven.