Spring-Kontexttests können keine Konfigurationsspeicherorte finden

8

Ich habe eine große Anwendung, die auf mehrere Spring-Bean-Definition-XML-Dateien verteilt ist. In meiner Testsuite lade ich manuell die benötigten XML-Dateien mit einem FileSystemXmlApplicationContext, um die Tests auszuführen, die ich ausführen möchte. Dies reduziert die Testzeit für die Installation und ermöglicht es mir, genau die gleichen Konfigurationsdateien zu verwenden, die in der Produktion verwendet werden.

Jetzt versuche ich Spring's transaktionale Testbasisklassen zu verwenden, die die Konfigurationsspeicherorte übernehmen und den Kontext für mich laden. Aus irgendeinem Grund, wenn der Anwendungskontext erstellt wird, kann Spring keine der Konfigurationsdateien finden. Das ist verwirrend, weil ich den Test vom selben Arbeitsverzeichnis aus führe, wie wenn ich die Konfiguration selbst mit FileSystemXmlApplicationContext lade. Wenn ich alle meine Konfigurationsspeicherorte mit "file:" voranlege, werden die Pfade gefunden, die ich in meinem Test angegeben habe, aber alle Dateien, die von in der Konfiguration definierten Beans importiert oder referenziert werden (z. B. Eigenschaftendateien), können nicht gefunden werden. Was ist das Problem? Kann ich Tests erhalten, die die Spring-Kontexttest-Klassen so erweitern, dass sie genauso funktionieren wie die, in denen ich den Kontext selbst erstellt habe?

Zum Beispiel funktioniert das Erstellen des Kontextes wie folgt:

%Vor%

Wenn ich AbstractTransactionalDataSourceSpringContextTests erweitere, findet das folgende nicht services-context.xml:

%Vor%

Dies findet services-context, aber der dort definierte PropertyPlaceholderConfigurer kann seine Eigenschaftendateien nicht finden.

%Vor%     
Adam B 17.06.2009, 20:26
quelle

6 Antworten

3

Zusätzlich zum Überschreiben von getConfigLocations habe ich auch loadContext überschrieben und einen vertrauenswürdigen fileSystemXmlApplicationContext dort verwendet.

%Vor%     
Adam B 17.06.2009, 21:31
quelle
4

Wir haben alle Spring-Konfigurations- und Eigenschaftendateien in den Klassenpfad gestellt, was die Dinge einfach hält - wir können einfach unsere Testklassen von einer Basisklasse wie:

erweitern %Vor%

Hier sind die Pfade alle Pfade im Klassenpfad.

Wenn Sie das nicht möchten, haben Sie überprüft, wie Sie auf die Eigenschaftendateien in Ihrer Datei services-context.xml verweisen? Ich vermute, dass wenn Sie file: zu Ihrer Kontextkonfiguration hinzufügen, müssen Sie dies auch zu Ihrer Eigenschaftendateireferenz hinzufügen. Sie könnten vielleicht einfach eine separate Test-Spring-Konfigurationsdatei verwenden, um die Definition Ihres Eigenschaftsplatzhalters zu ändern, und diese am Ende Ihrer Liste von Kontextdateien platzieren - ihre Definitionen überschreiben dann die in früheren Dateien definierten.

    
paulcm 18.06.2009 17:54
quelle
1

Ihre Konfigurationsspeicherorte sind relative URIs und werden von der Basistestklasse als solche interpretiert, wobei der URI relativ zum Speicherort der Testklasse selbst aufgelöst wird. Verwenden Sie vollständig qualifizierte URIs oder verwenden Sie den relativen URI, wobei Sie berücksichtigen, wo sich die Testklasse befindet.

    
skaffman 17.06.2009 21:01
quelle
1

Sie können keine Klassenpfad-XML-Factorys wie verwenden ClassPathXmlApplicationContext ?

    
λlεx 18.06.2009 18:06
quelle
0

Eine andere mögliche Lösung besteht darin, das services-config.xml zu duplizieren und als services-config-test.xml umzubenennen und dann unter classpath zu platzieren. Das Gleiche gilt für die Eigenschaftendatei.

    
zawhtut 17.04.2011 16:08
quelle
0
%Vor%     
janwen 25.06.2012 08:50
quelle

Tags und Links