En una de mis asignaciones anteriores tuvimos cientos de pruebas de integración con conjuntos de datos, aunque no en DBUnit — el entorno de prueba se escribió desde cero, ya que era una empresa muy grande que puede permitirse este tipo de cosas.
Los conjuntos de datos se organizaron jerárquicamente. El sistema bajo prueba consistió en unos pocos (5-10) módulos y los datos de prueba siguieron ese patrón. Una secuencia de comandos de prueba de unidad era la siguiente:
include(../../masterDataSet.txt)
include(../moduleDataSet.txt)
# unit-specific test data
someProperty=someData
Los nombres de propiedad se asignan directamente a los registros de base de datos por alguna herramienta extraña que no puedo recordar.
El mismo patrón se puede aplicar a las pruebas DBUnit. En conjunto de datos maestros puede colocar registros siempre debe ser — como diccionarios, la carga inicial de la base de datos, como si se va a instalar desde cero.
En conjunto de datos de módulo pondría registros que cubran casos de prueba de la mayoría de las pruebas en un módulo; No creo que una prueba promedio tuya involucre todas tus 70 tablas de base de datos, ¿o sí? Seguramente debe tener algunos grupos de funciones que podrían constituir un módulo, incluso si la aplicación es monolítica. Intenta organizar los datos de prueba a nivel de módulo a su alrededor.
Por último, en el nivel de prueba, solo modificaría su conjunto de prueba con un número mínimo de registros necesarios para estas pruebas en particular.
Este enfoque tiene el enorme beneficio de aprender; debido a que hay pocos archivos de datos, en el tiempo, realmente comienza a memorizarlos. En lugar de ver cientos de conjuntos de datos grandes que solo difieren en detalles imperceptibles (que debe descubrir cada vez que vuelve a realizar una prueba después de un tiempo), puede determinar con facilidad la diferencia entre dos conjuntos de datos.
Una palabra sobre el rendimiento al final. En mi 2.4 GHz 2-base de la máquina WinXP una prueba DBUnit que implica:
- dejando caer 14 mesas,
- la creación de 14 mesas,
- inserción de ca. 100 registros,
- realización de la lógica de prueba,
tarda 1-3 segundos. Los registros muestran que las primeras 3 operaciones toman menos de un segundo, la mayor parte del tiempo de prueba es consumido por Spring. Esta lógica es realizada por cada prueba, para evitar dependencias de orden de prueba. Todo se ejecuta en una máquina virtual con Derby integrado, esta es probablemente la razón por la cual es tan rápido.
EDIT: Creo que los conjuntos de datos XML DBUnit no son compatibles con la inclusión de otros archivos de prueba, se puede superar mediante el uso de una clase base para todas las pruebas de integración, por ejemplo:
public class AbstractITest {
@Before
public void setUp() throws Exception {
//
// drop and recreate tables here if needed; we use
// Spring's SimpleJdbcTemplate executing drop/create SQL
//
IDataSet masterDataSet = new FlatXmlDataSetBuilder().build("file://masterDataSet.xml");
DatabaseOperation.CLEAN_INSERT.execute(dbUnitConnection, dataSet);
}
}
public class AbstractModuleITest extends AbstractITest {
@Before
public void setUp() throws Exception {
super.setUp();
IDataSet moduleDataSet = new FlatXmlDataSetBuilder().build("file://moduleDataSet.xml");
DatabaseOperation.CLEAN_INSERT.execute(dbUnitConnection, moduleDataSet);
}
}
public class SomeITest extends AbstractModuleITest {
// The "setUp()" routine only here if needed, remember to call super.setUp().
@Test
public void someTest() { ... }
}
La pregunta es sobre el rendimiento, pero la verdadera preocupación parece ser "hacerlos mantenibles". En mi humilde opinión, debe centrarse absolutamente en la facilidad de mantenimiento y aumentar el rendimiento mediante la adición de más poder de cómputo. – Jayan
Tenga en cuenta que si utiliza múltiples conjuntos de datos pequeños con DBUnit, puede encontrarse con un desagradable problema de fallas aleatorias. Escribí una [publicación de blog explicando por qué y cómo solucionarlo] (http://www.andrewspencer.net/2011/solve-foreign-key-problems-in-dbunit-test-data/). –
Si anhela una Factory Girl para Java, eche un vistazo a https://github.com/mguymon/model-citizen – mguymon