¿Muchos conjuntos de datos de DBunit pequeños o uno grande?

Question

La difusión de datos de prueba en múltiples conjuntos de datos pequeños me parece para crear un dolor de cabeza de mantenimiento cada vez que se ajusta el esquema. ¿Alguien ve un problema con crear un solo conjunto de datos de prueba más grande? Por "más grande" todavía solo hablo de un par de cientos de registros en total.

Answer 1

No usaría un conjunto de datos grande único (desea evitar cualquier sobrecarga si no lo necesita) y seguir DBUnit's Mejores prácticas Recomendaciones:

Use múltiples conjuntos de datos pequeños

La mayoría de sus pruebas no requieren que la base de datos completa se reinicialice. Entonces, en lugar de colocar todos los datos de la base de datos en un conjunto de datos grande, intente dividirlos en muchos fragmentos más pequeños.

Estos fragmentos podrían corresponder aproximadamente a unidades lógicas o componentes. Esto reduce la sobrecarga causada por la inicialización de su base de datos para cada prueba. Esto también facilita el desarrollo del equipo ya que muchos desarrolladores que trabajan en diferentes componentes pueden modificar los conjuntos de datos de forma independiente.

Para pruebas integradas, aún puede usar la clase CompositedataSet para combinar lógicamente múltiples conjuntos de datos en uno grande en el tiempo de ejecución.

Algunos comentarios más de la unidad de las unidades:

Mantenimiento de la base de datos de prueba automática

Al escribir pruebas de base de datos, tenga en cuenta las pautas: las pautas:

• Use pequeños conjuntos de datos de prueba, que contengan la menor cantidad de datos posible. En sus archivos de datos, solo especifique columnas que se usan en columnas de unión o la cláusula WHERE de la consulta probada.
• Haga que la clase de prueba sea específica de la clase de prueba. No reutilice conjuntos de datos entre diferentes clases de prueba, por ejemplo, no use 1 conjunto de datos de dominio grande para todas sus clases de prueba. Hacerlo hará que sea muy difícil realizar cambios en sus datos de prueba para una prueba sin frenar nada para otra prueba. Está escribiendo una prueba unitaria y dicha prueba debe ser independiente de otras pruebas.
• No use demasiados conjuntos de datos. Cuantos más conjuntos de datos use, más mantenimiento se necesita. Intente reutilizar el conjunto de datos de TestClass para todas las pruebas en esa clase TestClass. Solo use conjuntos de datos de métodos si hace que sus pruebas sean más comprensibles y claras.
• Limite el uso de conjuntos de datos de resultados esperados. Si los usa, solo incluya las tablas y columnas que son importantes para la prueba y deje de lado el resto.
• Use un esquema de base de datos por desarrollador. Esto permite a los desarrolladores insertar datos de prueba y ejecutar pruebas sin interferir entre sí.
• Deshabilite todas las restricciones de clave extranjera y no nulas en las bases de datos de prueba. De esta manera, los archivos de datos no deben contener más datos de los que absolutamente necesarios

El uso de pequeños conjuntos de datos con suficientes datos ha funcionado decentemente para nosotros en el pasado. Claro, hay cierto mantenimiento si modifica la base de datos, pero esto es manejable con alguna organización.