Schärfen Sie Ihre DbUnit-Tests

DbUnit ist eine JUnit-Erweiterung und bei Entwicklern sehr beliebt für Unit-Tests von datenbankgestützten Projekten. In diesem Blog werde ich einige Tipps erörtern, die Ihnen das Leben mit DbUnit-Tests erleichtern und verschönern.

Verwendung derselben Verbindung für die gesamte Testsuite Wenn Sie DatabaseTestCase erweitern, erstellt diese Klasse in setUp() eine Verbindung zur Datenbank und schließt sie in teardown(). Dies kann sich als großer Overhead erweisen und die Ausführung von Tests erheblich verlangsamen, wenn die Anzahl der Testfälle steigt. Die Aufrechterhaltung einer einzigen Verbindung für die gesamte Testsuite kann sich in solchen Fällen als vorteilhaft erweisen. Wenn Sie JUnit 4 verwenden, können Sie Anmerkungen für die Durchführung anfänglicher Operationen verwenden (@BeforeClass) und müssen daher DatabaseTestCase nicht erweitern und das Schließen der Datenbankverbindung nicht abschließend behandeln. [java]@BeforeClass public static void setUpBeforeClass() throws Exception { handleSetUpOperation(); } [/java] Wenn mehrere Testfälle einen Nur-Lese-Datensatz als erwarteten Zustand der Datenbank nach der Ausführung der Testfälle verwenden, kann das Laden dieser erwarteten Datensatzdatei nur einmal für alle Testfälle zur Beschleunigung beitragen. Die Angabe einer DTD für das Dataset kann als Heilmittel für einige der Dinge dienen Sie können eine DTD erstellen, indem Sie den folgenden Code in DbUnit verwenden. [java]FlatDtdDataSet.write(connection.createDataSet(), new FileOutputStream("test.dtd")); [/java] Diese DTD kann nun verwendet werden, um

• Validieren Sie eine Dataset-Datei mit ihr.
• Bereitstellung von Nullwerten für eine Spalte, indem Sie sie für eine Zeile im Datensatz weglassen. Einige wiederverwendbare Methoden Einige wiederverwendbare Methoden, wie z.B. die Überprüfung des Datenbankzustands nach der Ausführung von Tests mit einer Datensatzdatei für den erwarteten Zustand, können sehr nützlich sein. Ich erwähne hier eine dieser Methoden [java] protected void assertTables(String filename, String[] tableNames) throws SQLException, Exception, DataSetException, IOException, DatabaseUnitException { IDataSet expectedDataSet = null; if (tableNames == null) { // Erwartete Daten aus einem XML-Datensatz laden expectedDataSet = new FlatXmlDataSet(new File(filename)); tableNames = expectedDataSet.getTableNames(); } sonst { // Teilmenge des kompletten Datensatzes laden expectedDataSet = new FilteredDataSet(tableNames, new FlatXmlDataSet(new File(filename))); } // Holen Sie Datenbankdaten nach der Ausführung Ihres Codes IDataSet actualDataSet = getConnection().createDataSet(tableNames); ITable[] expectedTables = new CompositeTable[tableNames.length]; for (int i = 0; i <tableNames.length; i++) { expectedTables[i] = new CompositeTable(expectedDataSet .getTableMetaData(tableNames[i]), actualDataSet .getTable(tableNames[i])); } Assertion.assertEquals(expectedDataSet, new CompositeDataSet( expectedTables)); } [/java] Die obige Methode assertTables kann den aktuellen Zustand der Datenbank nach der Ausführung von Testfällen mit dem in der Dataset-Datei angegebenen Zustand feststellen. Diese Methode ist intelligent genug, um beide Fälle zu behandeln, d.h. den Zustand der Datenbank mit der erwarteten Dataset-Datei durch Angabe von Tabellennamen (dies kann eine Teilmenge aller in der Dataset-Datei bereitgestellten Tabellen sein) oder ohne die Tabellennamen, wobei in diesem Fall alle in den Dataset-Dateien bereitgestellten Tabellen verwendet werden. In diesem Fall werden alle in den Dataset-Dateien enthaltenen Tabellen verwendet. Die Methode verwendet die in der Dataset-Datei enthaltenen Tabellen-Metadaten, um den Status der entsprechenden Tabelle aus der Datenbank abzurufen, so dass das Ignorieren von Spalten, wie z.B. automatisch generierten Spalten, automatisch vermieden werden kann, indem sie in der Dataset-Datei nicht erwähnt werden. Fröhliches Rot-Grün-Refactor-ing.