Oracle DBUnit/JUnit auf Oracle mit verschiedenen Schemata?

huhn57

Mitglied
Hi zusammen,
ich schreibe gerade JUnit-Tests für meine Java-Anwendung. Jetzt habe ich beispielsweise eine Methode wie diese hier:

Java:
    public static void test() {
        final String sqlStatement = "insert into test(id, text) values (1, 'hallo')";
        try {
            Connection conn = Hilfsklasse.getConnection([I]DatenbankschemaProd[/I]);
            final Statement stat = conn.createStatement();
            stat.executeUpdate(sqlStatement);
            conn.commit();
            stat.close();
            Hilfsklasse.closeConnection(conn);
        } catch (final SQLException e) {
            System.out.println(e.getMessage());
        }
    }

Wie gesagt, nur ein einfaches Beispiel, aber hier greife ich auf ein Oracle-Schema "DatenbankschemaProd" zu, in dem die Tabelle "test" liegt.

Wenn ich einen simplen JUnit-Test für diese Methode schreibe, stehen hinterher natürlich zwei gleichlautende Datensätze in der Tabelle "test". Von daher möchte ich an dieser Stelle gerne mit DBUnit arbeiten: im setUp eine leere Tabelle (z.B. im Datenbankschema "test") erzeugen, dann in einem JUnit-Test die Methode aufrufen und prüfen, ob der Datensatz hinzugefügt wurde, und im tearDown die Tabelle wieder leeren/löschen etc.

So weit auch so gut. Mein Problem ist: rufe ich in einem Test diese Methode auf, erfolgt hier natürlich der Zugriff auf das "DatenbankschemaProd" und nicht, wie ich es gerne hätte, auf die von mir für den Test erzeugte Tabelle. Vielleicht habe ich auch gerade ein großes Brett vorm Kopf, aber wie müßte ich meine Methode umstellen, um den von mir gewünschten Effekt zu erreichen? Das Datenbankschema als Parameter zu übergeben ginge zwar auch, fände ich aber nicht so schön.

Bin für jede Anregung dankbar!

Viele Grüße vom Huhn
 
Wieso hantierst du mit SQL Code & JDBC, wenn DBUnit doch Datasets und DatabaseOperation unterstützt?
Datasets erstelle ich immer als Strings, nicht in (XML) Dateien.
Dein try/catch Block ist sehr schlecht für Tests, eigentlich ungeeignet, lass ihn weg 😉

Ansosnten sollte doch kein eigenes Schema für den Test auf der Prod DB erzeugt werden, nimm eine eigene DB fürs Testen.
 
Sorry, habe mich mißverständlich ausgedrückt...

Die Beispielmethode von oben ist keine Testmethode (das wäre auch schön doof), sondern die Methode, die ich testen möchte. Ich habe sie aus Übersichtsgründen ein bißchen gekürzt und natürlich eine andere Datenbankabfrage genommen.

Die zugehörige Testklasse sieht dann z.B. so aus:

Java:
public final class TestTestklasse extends DatabaseTestCase {

   ...

    @Test
    public void testTestmethode() {
        ...
    }

Hoffe, das war jetzt klarer 🙂
 
Im Prod code ein Schema fest vorzugeben ist keine gute Idee, sonst tut man sich sehr schwer mit dem Testen/Entwickeln.
Sowas sollte über Konfiguration (XML/Properties Dateien) gesteuert werden, sowie die restlichen Angaben (Server, User & Passwort) auch.
Was ich über DatabaseOperastion & Datasets sagte stimmt übrigens immer noch 😉
 
Die Zugriffsdaten für Entwickler- und Prod-Schema sind in .properties-Dateien gespeichert. Nur würde ich gerne ein anderes Schema verwenden als das Schema, das gezogen wird, wenn ich die Tests lokal starte. D.h. hier sollte nach Möglichkeit eine andere properties-Datei gezogen werden. Oder kann man sowas in einem ant-Task definieren?

Zum Thema Datasets und DatabaseOperation:
ich war bisher der Ansicht, dass es sinniger ist, die ausgeführten Methoden direkt zu testen, als mit DatabaseOperations die Operationen auf einer Tabelle zu testen. Vor allem dann, wenn ich in meiner Methode noch Eingabeparameter habe, die ich vorher auf Plausibilität teste. Oder sehe ich das falsch?
 
Die Zugriffsdaten für Entwickler- und Prod-Schema sind in .properties-Dateien gespeichert. Nur würde ich gerne ein anderes Schema verwenden als das Schema, das gezogen wird, wenn ich die Tests lokal starte. D.h. hier sollte nach Möglichkeit eine andere properties-Datei gezogen werden. Oder kann man sowas in einem ant-Task definieren?
Wie jetzt?
Du kannst das konfigurieren, möchtest die Konfiguration aber ignorieren?
Vielleciht verstehe ich dich da wieder falsch...
Auch mit Ant kann man für die Tests verscheidene Propertydateien nutzen.

um Thema Datasets und DatabaseOperation:
ich war bisher der Ansicht, dass es sinniger ist, die ausgeführten Methoden direkt zu testen, als mit DatabaseOperations die Operationen auf einer Tabelle zu testen. Vor allem dann, wenn ich in meiner Methode noch Eingabeparameter habe, die ich vorher auf Plausibilität teste. Oder sehe ich das falsch?
Da siehst du etwas falsch.
Es geht nicht um den eigentlichen Test (Exercise), sondern um das Setup und den Teardown.
Du willst ja jeden deiner Tests auf einem vordefinierten Zustand von Daten ausführen lassen.
 
Ich scheine heute echt Probleme zu haben, mich auszudrücken 😳

Die Standard-properties-Datei wird geladen, wenn ich das Projekt lokal starte. Dort sind die Zugangsdaten für die Test-Datenbank hinterlegt. Ich würde für JUnit/DBUnit gerne noch eine andere Datenbank nehmen. Kann auch gerne über ein ganz anderes DBMS laufen, z.B. HSQLDB. Egal was, so, wie die Methode aufgebaut ist, funktioniert das ja nicht. Vielleicht muß ich auch komplett die Struktur in meiner Anwendung ändern?

Hast du ein Beispiel, wie man eine properties-Datei nur für JUnit/DBUnit über ant hinterlegen kann?

Okay, ich habe mir eine solche Testklasse wie folgt gedacht:
- setUp: Erstellen/Leeren einer Datenbanktabelle, ggf. mit benötigten Testdaten füllen
- tearDown: Leeren/Löschen der Tabelle
- eine Testmethode (Bsp.): Funktion ausführen, Zustand der Tabelle (nach Insert/Update/Delete) bzw. erhaltenes Suchergebnis aus Select prüfen

Ist das vom Grundsatz her verkehrt?

Danke dir schonmal ganzherzlich für deine Geduld!
 
Jetzt wirds klarer 🙂

Mit Ant arbeite ich seit Jahren nicht mehr, (nutze Maven2), sollte sich aber per Google finden lassen.

Okay, ich habe mir eine solche Testklasse wie folgt gedacht:
- setUp: Erstellen/Leeren einer Datenbanktabelle, ggf. mit benötigten Testdaten füllen
- tearDown: Leeren/Löschen der Tabelle
- eine Testmethode (Bsp.): Funktion ausführen, Zustand der Tabelle (nach Insert/Update/Delete) bzw. erhaltenes Suchergebnis aus Select prüfen
Ja, so in etwa, nochmals langsam:
Sog. 4 Phasen Tests bestehen aus 4 Phasen (*g*)
1. Setup - alles was der Test braucht wird hier bereitgestellt, zB. Schema, Tabellen und Daten
2. Exercise - die zu testende Methode wird aufgerufen
3. Verify - Die Ergebnisse werden überprüft
4. Teardown - hier wird aufgeräumt (Schema, Tabellen und/ oder Daten, je nachdem)

DBUnit bietet Unterstützung für alle diese Phasen, kannst es natürlich auch alles selber machen.

Noch als Tipp: Back Door Manipulation at XUnitPatterns.com
Bei "Example: Back Door Fixture Setup " wird es imho für dich interessant, das drumherum solltest du auch verstanden haben.
 

Zurück
Oben