JUnit für Datenbank-code
Habe ich versucht zu implementieren, unit-Tests und derzeit haben einige code, der Folgendes macht:
- Abfrage der externen Datenbank laden
in einer feed-Tabelle - Abfrage eine Ansicht,
das ist ein delta aus meine Feeds und Daten
Tabellen, Aktualisierung der Daten-Tabelle übereinstimmen
feed-Tabelle
mein unit-Test-Strategie ist diese:
Habe ich eine Test-Datenbank, die ich bin frei, zu manipulieren.
- in setUP(), laden Sie einige Daten in meine Test db
- mein code, mit meiner Test db als Quelle
- überprüfen Sie die Daten-Tabelle, die überprüfung für die zählt, und die Existenz/nicht Existenz von bestimmten Aufzeichnungen
- klare Test-db zu laden, in einen anderen Satz von Daten
- führen Sie den code erneut
- inspizieren die Daten der Tabelle wieder
Natürlich habe ich die Daten-sets, die ich für das laden in der Quell-db einrichten, so dass ich weiß, bestimmte Datensätze Hinzugefügt werden sollen,gelöscht,aktualisiert, etc.
Wie es scheint, das ist ein bisschen umständlich und es sollte einen einfacheren Weg? irgendwelche Vorschläge?
Schreibe einen Kommentar
Du musst angemeldet sein, um einen Kommentar abzugeben.
Ist es Ihre Absicht, zu testen, die anzeigen, die generiert die deltas, oder um zu testen, ob dein code korrekt hinzufügt, löscht und aktualisiert, die in Reaktion auf die Aussicht?
Wenn Sie möchten, testen Sie die Ansicht, Sie könnte verwenden Sie ein tool wie DBUnit füllen Sie Ihre Futter-und Daten-Tabellen mit verschiedenen Daten, deren delta haben Sie manuell berechnet. Dann, für jeden test, den Sie bestätigen möchten, dass die Ansicht gibt einen passenden Satz.
Wenn Sie testen möchten, wie der code reagiert auf Veränderungen erkannt, die von der Ansicht, ich würde versuchen, zu abstrahieren Datenbank zugreifen. Ich stellen Sie sich eine java-Methode, die können Sie ein ResultSet (oder eine Liste von POJO/DTO) und gibt eine Liste von parameter-Objekt-arrays (wieder, oder POJO ' s) Hinzugefügt werden. Andere Methoden analysieren die diff-Liste für Elemente werden entfernt und aktualisiert werden. Sie könnten dann erstellen Sie ein mock-ResultSet-oder pojo ' s, geben Sie Ihren code ein und überprüfen Sie die korrekten Parameter werden zurückgegeben. Alles ohne berühren einer Datenbank.
Ich denke, der Schlüssel ist zu brechen, Ihren Prozess in Teile und prüfen jedes von diesen so unabhängig wie möglich.
DbUnit Ihre Bedürfnisse zu erfüllen. Eine Sache zu beachten ist, dass Sie gewechselt haben, mit SLF4J als Ihre logging-Fassade anstelle von JCL. Sie können konfigurieren, SLF4J für die Weiterleitung der Anmeldung an die JCL-aber seien Sie gewarnt, wenn Sie mit Maven DbUnit saugt Ihre Nop-Protokoll-Anbieter standardmäßig, so müssen Sie einen Ausschluss, ich gebloggt über diesen Konflikt kürzlich.
Ich verwenden, DbUnit, aber auch ich arbeite sehr hart, um nicht zu Tests gegen die DB.
Tests, die gegen die Datenbank muss existieren nur für die Zwecke der Prüfung der Datenbank-Schnittstelle.
Also ich habe die Mock-Db-Verbindungen, die ich einstellen kann das die Daten für die Verwendung in allen den rest meines tests.
Abgesehen von den bereits vorgeschlagenen DBUnit, möchten Sie vielleicht zu schauen in Unitils. Es verwendet, DBUnit, bietet aber mehr als das (Zitat von der Website):
Wenn Sie mithilfe von Maven, eine Möglichkeit ist die Verwendung der sql-maven-plugin. Es ermöglicht die Ausführung von Datenbank-Initialisierung/Bevölkerung-Skripts während des maven-build-Zyklus.