JPA - Cómo truncar tablas entre pruebas unitarias

Question

Quiero limpiar la base de datos después de cada caso de prueba sin deshacer la transacción. He intentado con DBUnit DatabaseOperation.DELETE_ALL, pero no funciona si una eliminación viola una restricción de clave externa. Sé que puedo desactivar las comprobaciones de claves externas, pero eso también desactivaría las comprobaciones de las pruebas (que quiero evitar).

Estoy usando JUnit 4, JPA 2.0 (Eclipselink) y la base de datos en memoria de Derby. ¿Algunas ideas?

Gracias, Theo

Answer 1

Simple: antes de cada prueba, comience una nueva transacción y después de la prueba, deshagala.Eso le dará la misma base de datos que tenía antes.

Asegúrese de que las pruebas no creen nuevas transacciones; en su lugar reutilizar el existente.

Answer 2

estoy un poco confundido en cuanto DBUnit se reiniciará la base de datos a un estado conocido antes de cada prueba.

También recommend as a best practice no limpiar o cambiar los datos después de la prueba.

Así que si es la limpieza lo que debes hacer es preparar la base de datos para la siguiente prueba, no me molestaría.

Answer 3

Sí, la prueba en la transacción haría su vida mucho más fácil, pero si la transacción es lo suyo, entonces necesita implementar transacción (es) de compensación durante la limpieza (en @After). Suena laborioso y podría ser, pero si se aborda adecuadamente puede terminar con un conjunto de métodos de ayuda (en pruebas) que compensan (limpieza) los datos acumulados durante @Before y pruebas (utilizando JPA o JDBC directo, lo que sea lógico).

Por ejemplo, si se utiliza JPA y llama a crear métodos en entidades durante las pruebas puede utilizar (usando AOP si te apetece o simplemente métodos de ensayo auxiliares como nosotros) un patrón en todas las pruebas de:

1. pista los identificadores de todas las entidades que se han creado durante la prueba
2. ellos se acumulan en orden creado
3. entidad repetición borra de estas entidades en el orden inverso en @After

Answer 4

Mi configuración es bastante similar: es Derby (integrado) + OpenJPA 1.2.2 + DBUnit. Así es como yo manejo las pruebas de integración para mi tarea actual: en cada método @Before corro 3 guiones:

1. gota DB — una secuencia de comandos SQL que cae todas las tablas.
2. Cree DB — un script SQL que los vuelva a crear.
3. Una secuencia de comandos XML de unidad de base de datos específica de prueba para completar los datos.

Mi base de datos tiene solo 12 tablas y el conjunto de datos de prueba no es muy grande, ya sea — aproximadamente 50 registros. Cada script tarda unos 500 ms en ejecutarse y los mantengo de forma manual cuando las tablas se agregan o modifican.

Este enfoque probablemente no se recomienda para probar bases de datos grandes, y tal vez ni siquiera puede considerarse una buena práctica para las pequeñas; sin embargo, tiene una ventaja importante sobre la reversión de la transacción en el método @After: en realidad puede detectar lo que sucede en la confirmación (como entidades separadas persistentes o excepciones de bloqueo optimista).

Answer 5

La forma más sencilla de hacerlo es probablemente utilizar el método nativeQuery jpa.

@After 
public void cleanup() { 
    EntityManager em = entityManagerFactory.createEntityManager(); 
    em.getTransaction().begin(); 
    em.createNativeQuery("truncate table person").executeUpdate(); 
    em.createNativeQuery("truncate table preferences").executeUpdate(); 
    em.getTransaction().commit(); 
}