Ich habe versucht, Komponententests zu implementieren und verfüge derzeit über Code, der Folgendes bewirkt:
Meine Unit-Teststrategie ist dies:
Ich habe eine Testdatenbank, die ich frei manipulieren kann.
Offensichtlich habe ich die Datensätze, die ich in die Quelldatenbank geladen habe, so dass ich weiß, dass bestimmte Datensätze hinzugefügt, gelöscht, aktualisiert werden sollen, usw.
Es sieht so aus, als wäre das ein bisschen umständlich und es sollte einen einfacheren Weg geben? irgendwelche Vorschläge?
Ist es Ihre Absicht, die Ansicht zu testen, die die Deltas generiert, oder zu testen, ob Ihr Code als Reaktion auf die Ansicht korrekt hinzugefügt, gelöscht und aktualisiert wird?
Wenn Sie die Ansicht testen möchten, könnten Sie ein Tool wie DBUnit verwenden, um Ihre Feed- und Datentabellen mit verschiedenen Daten zu füllen Delta haben Sie manuell berechnet. Dann würden Sie für jeden Test verifizieren, dass die Ansicht einen passenden Satz zurückgibt.
Wenn Sie testen möchten, wie Ihr Code auf von der Ansicht erkannte Diffs reagiert, würde ich versuchen, den Datenbankzugriff wegzuspulen. Ich stelle mir eine Java-Methode vor, zu der Sie eine Ergebnismenge (oder eine Liste von POJO / DTOs) übergeben können und eine Liste von Parametern, die Objektarrays (wieder oder POJOs) hinzugefügt werden sollen, zurückgibt. Andere Methoden würden die Diff-Liste für zu entfernende und zu aktualisierende Elemente analysieren. Sie könnten dann eine falsche Ergebnismenge oder Pojo's erstellen, diese an Ihren Code übergeben und überprüfen, ob die richtigen Parameter zurückgegeben wurden. Alles ohne eine Datenbank zu berühren.
Ich denke, der Schlüssel ist, Ihren Prozess in Teile zu zerlegen und jeden davon so unabhängig wie möglich zu testen.
DbUnit wird Ihre Anforderungen erfüllen. Eine Sache, auf die Sie achten sollten, ist, dass sie SLF4J anstelle von JCL als Protokollierungsfassade verwenden. Sie können SLF4J so konfigurieren, dass die Protokollierung an JCL weitergeleitet wird. Sie sollten jedoch gewarnt werden, wenn Maven DbUnit standardmäßig in ihrem Nop-Protokoll-Provider saugt, so dass Sie einen Ausschluss verwenden müssen. I hat kürzlich über diesen Konflikt gebloggt.
Ich benutze DbUnit, aber ich arbeite auch sehr hart, um nicht gegen die DB testen zu müssen. Tests, die gegen die Datenbank laufen, sollten nur zum Testen der Datenbankschnittstelle existieren. Also habe ich Mock Db Connections, dass ich die Daten für den Rest meiner Tests einstellen kann.
Abgesehen von der bereits vorgeschlagenen DBUnit, sollten Sie sich in Untils umsehen. Es verwendet DBUnit, bietet aber mehr als das (Zitat von der Site):
- Automatische Wartung von Datenbanken mit Unterstützung für inkrementelle, wiederholbare und nachbearbeitende Skripts
- Abhängigkeiten automatisch deaktivieren und Sequenzen auf einen Mindestwert setzen
- Unterstützung für Oracle, Hsqldb, MySql, DB2, Postgresql, MsSql und Derby
- Vereinfachen Sie die Einrichtung der Testdatenbankverbindung
- Einfaches Einfügen von Testdaten mit DBUnit * Führen Sie Tests in einer Transaktion durch
- JPA-Entity-Manager-Erstellung und -Injektion für Hibernate, Toplink und * Hibernate SessionFactory erstellen und Sitzung
- Testen Sie automatisch die Zuordnung von JPA-Entitäten / Hibernate-Mapped Objekte mit der Datenbank
Wenn Sie Maven verwenden, können Sie das sql-maven-plugin verwenden. Es ermöglicht Ihnen, Datenbankinitialisierungs- / Populationsskripts während des Maven-Build-Zyklus auszuführen.
Tags und Links java unit-testing database junit