In uno dei miei precedenti incarichi abbiamo avuto centinaia di test di integrazione che coinvolgono set di dati, anche se non in DBUnit — l'ambiente di test è stato scritto da zero, come è stata una società molto grande che può permettersi questo tipo di cose.
I set di dati erano organizzati in ordine gerarchico. Il sistema in prova consisteva in pochi (5-10) moduli e i dati di test seguivano quel modello. Uno script di test di unità si presentava così:
include(../../masterDataSet.txt)
include(../moduleDataSet.txt)
# unit-specific test data
someProperty=someData
I nomi delle proprietà sono stati mappati direttamente ai record DB da qualche bizzarro strumento non riesco a ricordare.
Lo stesso modello può essere applicato ai test DBUnit. Nel set di dati master è possibile inserire i record sempre come — come dizionari, caricamento iniziale del database, come se dovesse essere installato da zero.
Nel set di dati del modulo si inseriscono record di casi di test della maggior parte dei test in un modulo; Non credo che un tuo test medio coinvolga tutte le tue 70 tabelle del database, vero? È sicuramente necessario disporre di alcuni gruppi di funzionalità che potrebbero costituire un modulo, anche se l'applicazione è monolitica. Prova ad organizzare i dati di test a livello di modulo attorno ad esso.
Infine, al livello di test, si modifica solo il set di test con un numero minimo di record necessari per questo test particolare.
Questo approccio ha l'enorme vantaggio dell'apprendimento; perché ci sono pochi file di dati, in tempo, in realtà inizi a memorizzarli. Invece di vedere centinaia di grandi insiemi di dati che differiscono solo da dettagli non percepibili (che devi scoprire ogni volta che torni a un test dopo un po '), puoi facilmente capire quanto siano diversi i due set di dati.
Una parola sulla prestazione alla fine. Sul mio 2.4 GHz 2-nucleo WinXP macchina un test DBUnit coinvolge:
- cadere 14 tavoli,
- creazione 14 tavoli,
- inserimento ca. 100 record,
- eseguire la logica di test,
richiederà 1-3 secondi. I registri mostrano che le prime 3 operazioni richiedono meno di un secondo, la maggior parte del tempo di test viene consumata da Spring. Questa logica viene eseguita da ciascun test, per evitare le dipendenze degli ordini di test. Tutto funziona in una VM con Derby incorporato, questo è probabilmente il motivo per cui è così veloce.
EDIT: Penso che i set di dati DBUnit XML non supportano l'inclusione di altri file di test, può essere superato utilizzando una classe base per tutti i test di integrazione, ad esempio:
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 domanda è: per le prestazioni, ma la vera preoccupazione sembra essere "renderli mantenibili". IMHO, dovresti concentrarti assolutamente sulla manutenibilità e aumentare le prestazioni aggiungendo più potenza di calcolo. – Jayan
Tieni presente che se si utilizzano più set di dati di piccole dimensioni con DBUnit, è possibile incorrere in un brutto problema di errori casuali. Ho scritto un [post sul blog che spiega perché e come aggirarlo] (http://www.andrewspencer.net/2011/solve-foreign-key-problems-in-dbunit-test-data/). –
Se desideri una Factory Girl per Java, dai uno sguardo a https://github.com/mguymon/model-citizen – mguymon