Auflösen von zirkulären Maven-Abhängigkeiten zwischen Test, Testhelper und Projekt-unter-Tests

Question

Ich bin folgendermaßen vorgegangen. Ich habe Projekt A und ein Testprojekt in Abhängigkeit von A :

A <- A_t

Ich habe auch andere Projekte je nach A (und ihre Tests):

A <- B <- B_t

Um einige der Tests zu vereinfachen, führe ich eine neue Bibliothek ein, die beim Testen von Dingen hilft, die auf A :

A <- Atesthelper

Also A_t (und B_t ) hängt von dieser Testhilfe ab, etwa so:

A <- A_t
^    |
|    v
Atesthelper

Wenn ich jedoch Maven-Projekte (pom.xml) erstelle, scheint es üblich zu sein, sowohl das Projekt als auch den Test dieses Projekts in der gleichen pom.xml zu bündeln. Und ich erstelle eine neue pom.xml für die Atesthelper

Jetzt heißt es also:

(A <- A_t)
  ^    |
  |    v
Atesthelper

Das ist eine zirkuläre Abhängigkeit. Ist es möglich, in der pom.xml, irgendwie angeben, dass Atesthelper ist nur eine Abhängigkeit vom Testaufbauziel und nicht vom A Modul an sich?

Die Baureihenfolge sollte also sein: A, Atesthelper, A_t. D.h. A und A_t, die im selben Pom angegeben sind, sollten nicht gleichzeitig gebaut werden.

Vielen Dank im Voraus.

Answer 1

Wenn ich Sie richtig verstehe, ist Ihr Hauptziel die Wiederverwendung von Testklassen. A_t und Atesthelper sind keine Maven-Projekte, sie sind Tests.

Bringen Sie Maven dazu, ein jar aus Ihrem src/test/java zu erstellen. Siehe http://maven.apache.org/guides/mini/guide-attached-tests.html

Nach der Erstellung von A erhalten Sie A.jar und A-tests.jar. A-tests.jar enthält Atesthelper und A_t.

Setzen Sie die Abhängigkeit von B auf A-tests.jar ( <type>test-jar</type>) .

Answer 2

Das Problem, das Sie lösen müssen, ist die Abhängigkeit von Atesthelper a A dann wird alles andere gut funktionieren: A hängt ab von Atesthelper , B hängt ab von Atesthelper und beide A y B wird sowohl Quellen als auch Tests enthalten. Atesthelper wird in den Geltungsbereich aufgenommen Test in beiden A y B . Das ist Ihr Zielzustand.

Wie kommt man dorthin? Sie müssen die Elemente extrahieren, die Atesthelper in ein separates Projekt umgewandelt wird. Typischerweise handelt es sich dabei um Schnittstellen oder andere gemeinsame Funktionen, die ohnehin in ein separates Projekt ausgelagert werden sollten - nennen wir es ACommon . Ihr Ziellayout sollte also wie folgt aussehen:

ACommon <- Atesthelper
       ^    ^
       |   /
         A (and also B)

Welche Art von Funktionalität ist Atesthelper abhängig von in A ? Können Sie es in ein separates Projekt verschieben ( ACommon )?

Answer 3

Sie haben Ihre POMs nicht eingefügt und ich bin nicht sicher, ob ich Sie richtig verstehe, aber ich werde versuchen, Ihnen zu helfen, wie ich es verstanden habe. Dies ist ein recht häufiger Fall, der normalerweise so gelöst werden sollte:

Ihr Atesthelper Artefakt (wahrscheinlich jar Paketierung), die das Testen unterstützt, sollten alle testbezogenen Daten in der src/main Verzeichnis (also Klassen in src/main/java , Ressourcen in src/main/resources , etc.), nicht src/test ! Alle seine Abhängigkeiten, also A , aber auch Dinge wie JUnit, EasyMock (alles, was Klassen zur Testunterstützung brauchen) deklarieren Sie mit compile Bereich, der natürlich der Standardbereich ist. Verwenden Sie nicht test Umfang hier! Schließlich, in A y B Artefakte, deklarieren Atesthelper als Abhängigkeit von test Umfang.

Diese Lösung funktioniert bei mir seit vielen Jahren hervorragend. Sie ist sauber und geradlinig in Bezug auf Abhängigkeiten (sie sind transitiv im Gegensatz zu <type>test-jar</type> -basierten Lösung, wenn Sie wissen, was ich meine). Wie auch immer, benutzen Sie es einfach. Du wirst glücklich sein ;).

Answer 4

Der sauberste Weg, dieses Problem zu lösen, besteht darin, die Projekte getrennt zu halten. Es gibt Frameworks wie Maven, die Sie ermutigen, Klassen und Testklassen in ein einziges Projekt zu packen. Eclipse PlugIn Projekte zum Beispiel haben separate Testprojekte. Erstellung von A_t ein Teilprojekt von A scheint die beste Lösung zu sein, da Sie alle Abhängigkeiten, die Sie wollen, in diesem Testprojekt wiederverwenden können, ohne sich Gedanken über die Auswirkungen auf A .

Dieses Szenario wird häufiger auftreten, und Sie möchten Ihr Projektdesign vielleicht nicht mit Abhängigkeiten von Tests belasten. Diese Tests sollten unabhängig sein und Ihr Klassendesign nicht beeinflussen.