Ich suche nach Best Practices für die Einrichtung von Unit- und Integrationstests mit Spring.
Ich verwende normalerweise drei Arten von Tests:
Momentan habe ich nur Tests der zweiten Kategorie, das ist der knifflige Teil. Ich richte eine Basis-Test-Klasse ein wie:
%Vor%Und "Einheit" testet wie:
%Vor%mit Autowired-Attributen.
Was ist der beste Weg, den Test in einer anderen (Integrationstest-) Umgebung auszuführen? Unterklasse den Test und überschreiben die ContextConfiguration?
%Vor%Würde das funktionieren (ich kann es derzeit nicht einfach testen)? Das Problem bei diesem Ansatz ist, dass "@ContextConfiguration (locations = { "/my_spring_integration_test.xml"})" viel dupliziert wird.
Irgendwelche Vorschläge?
Grüße, Florian
ich die GenericXmlContextLoader
public class MyContextLoader extends GenericXmlContextLoader {
und überschreibe das
protected String[] generateDefaultLocations(Class<?> clazz)
Methode, um die Konfigurationsdateinamen eines Verzeichnisses zu sammeln, das ich mit einer SystemProperty angeben kann (-Dtest.config =).
Ich habe auch die folgende Methode geändert, um keine Orte zu ändern
%Vor%Ich verwende diesen Kontextlader wie folgt
%Vor%Wenn Sie den Test mit einer SystemProperty ausführen, die die Quelle der Konfigurationsdateien angibt, können Sie jetzt völlig andere Konfigurationen verwenden.
Die Verwendung einer SystemProperty ist natürlich nur eine Strategie, um den Konfigurationsort anzugeben. Sie können tun, was Sie wollen in generateDefaultLocations() .
BEARBEITEN:
Mit dieser Lösung können Sie verschiedene Konfigurationen für den Anwendungskontext (z. B. für Mock-Objekte) und nicht nur verschiedene Eigenschaften verwenden. Sie benötigen keinen Build-Schritt, um alles an Ihrem "Classpath" -Standort bereitzustellen. Meine konkrete Umsetzung verwendete auch die Benutzer als Standardnamen für ein Konfigurationsverzeichnis suchen (src / test / resources / {user}), wenn keine Systemeigenschaft gegeben ist (macht es einfach für alle Entwickler auf dem projektspezifischen Testumgebungen zu erhalten).
Die Verwendung des PropertyPlaceholder ist weiterhin möglich und empfohlen.
BEARBEITEN :
Frühling Version 3.1.0 unterstützt XML-Profile / Umwelt Abstraktion ähnelt meiner Lösung und ermöglicht die Auswahl von Konfigurationsdateien für verschiedene Umgebungen / Profile.
Ich würde mit dieser Version gehen:
%Vor% und in my_spring_test.xml , würde ich die PropertyPlaceHolderConfigurer Mechanismus.
Beispiel für JPA:
%Vor%Jetzt müssen Sie nur noch unterschiedliche Versionen von test.properties im Klassenpfad für In-Memory- und echte Integrationstests haben (und natürlich müssen die jeweiligen Treiberklassen vorhanden sein). Sie können sogar Systemeigenschaften festlegen, um die Eigenschaftswerte zu überschreiben.
Wenn Sie dies mit maven vorbereiten möchten, werden Sie feststellen, dass das Kopieren von Dateien mit maven nicht trivial ist. Sie benötigen eine Möglichkeit, Code auszuführen, wobei die Standardauswahl das maven-antrun-plugin und
In jedem Fall: zwei Konfigurationsdateien haben, z.B. in src / main / config und füge zwei Plugin-Ausführungen hinzu, eine in Phase generate-test-resources und eine in Phase pre-integration-test . Hier ist die GMaven-Version:
Ich habe keinen Erfolg bei der Verwendung von Spring 3.x context: property-placeholder-Tag. Ich habe den alten Modebohnen-Tag zusammen mit einer Eigenschaftendatei verwendet und konnte so eine Verbindung zwischen meinem Code und meiner Datenbank herstellen:
%Vor%Hier ist ein Beispiel für die Eigenschaftendatei:
%Vor%Dann richte ich meinen JUnit-Test so ein:
%Vor%Das hat für mich funktioniert, aber jeder macht die Dinge ein bisschen anders. Hoffe, das hilft.
Ich bin kürzlich auf dasselbe Problem gestoßen und habe mir die Dokumentation für die @ContextConfiguration-Annotation bemerkte ich die Option inheritLocations .
Durch Hinzufügen zu meiner Klasse, z. B.
%Vor%Ich habe festgestellt, dass ich die ContextConfiguration wie gewünscht überschreiben konnte.
Tags und Links java unit-testing spring integration-testing maven-2