Pruebas de integración - Hibernate & Dbunit

Question

Estoy escribiendo algunas pruebas de integraciones en Junit. Lo que sucede aquí es que cuando ejecuto todas las pruebas en una fila (y no por separado), los datos persistieron en la base de datos siempre cambia y las pruebas encuentran datos inesperados (insertados por la prueba anterior) durante su ejecución.

Estaba pensando en usar DBunit, pero me pregunto si restablece el índice de incremento automático entre cada ejecución o no (porque las pruebas también verifican las ID de las entidades persistidas).

Gracias

METRO.

Answer 1

Es una mejor práctica poner su base de datos en un estado conocido antes de Una ejecución de prueba y DBUNIT proporcionan todo lo requerido para eso. Pero no confíe en columnas incrementadas automáticas, colóquelas también en su conjunto de datos DBUNIT. Pros: puede verificar manualmente el estado de la base de datos después de ejecutar una prueba que falla. Contras: necesita configurar y mantener conjuntos de datos.

El otro enfoque es ejecutar cada método de prueba dentro de una transacción (y revertir la transacción al final de la ejecución). Pros: los datos son más fáciles de configurar y mantener (en el sés de datos). Contras: arreglar una prueba fallida es menos conveniente.

Answer 2

Puede ejecutar pruebas individuales o si se aplican grupos de pruebas como una sola transacción, y luego volver al final. (Esto podría ser difícil si las pruebas en sí comprenden múltiples transacciones y su DB no admite transacciones anidadas o puntos de salvación).

Alternativamente, realice su base de datos de prueba creada por scripts. DBUnit puede ayudar aquí, al igual que otros generadores de bases de datos, como Licenciatura, DBMaintain, dbmigrato Luego puede eliminar toda la base de datos y recrear para cada prueba de prueba o prueba. La utilidad de este enfoque disminuye a medida que el conjunto de datos de prueba se vuelve grande y aumenta la sobrecarga.

Una opción final es no hacer que sus pruebas dependan de la ID generada, ya que dependiendo del valor generado creará pruebas frágiles. Es útil probar la ID generada, así que pruebe estos valores para algunas pruebas, pero no estoy seguro de que haya valor en probar las ID para todas las pruebas.

Editar: El OP preguntó sobre el uso de Hibernate para recrear el esquema. Esto se puede organizar creando una nueva SessionFactory para cada prueba y estableciendo el "Hibernate.hbm2ddl.auto" para "verdadero" al construir la Factory de Session. Menciono la disminución de la efectividad del creación de caída: también se aplica a este caso.

Answer 3

Es malo confiar en los valores de identificación en una prueba, porque el auto-incremento es solo una base de datos. Por lo tanto, nunca verificaría las ID, porque si lo hace, su prueba depende de que las entidades estén llenas de valores de identificación particulares que no es un ejemplo de la vida real. Una prueba debe ser independiente de las ID de auto-incremento.

Answer 4

Esencialmente, este problema se puede resolver de dos maneras.

1. Envuelva sus pruebas relacionadas con DB dentro de una transacción. Antes de la prueba, comience la transacción. Una vez que termina la ejecución de la prueba, aborta la transacción siempre aborta la transacción. De esta manera, no se conservarían los cambios realizados en la prueba.

2. Use algo como DBUNIT, etc. para simular las clases relacionadas con las operaciones de DB para que ningún datos haya llegado a DB y sus clases devuelvan los resultados como si se hubiera realizado la operación de DB.

Si accede a DB al ejecutar sus pruebas, prefiero el enfoque 1.