Ich habe eine Multiprojektkonfiguration und möchte gradle verwenden.

Meine Projekte sind wie folgt:

• Projekt A.

  • -> src/main/java
  • -> src/test/java

• Projekt B.

  • -> src/main/java(abhängig src/main/javavon Projekt A )
  • -> src/test/java(abhängig src/test/javavon Projekt A )

Meine Projekt B- build.gradle Datei sieht folgendermaßen aus:

apply plugin: 'java'
dependencies {
  compile project(':ProjectA')
}

Die Aufgabe compileJavafunktioniert hervorragend, aber compileTestJavadie Testdatei wird nicht aus Projekt A kompiliert .

Veraltet - Verwenden Sie für Gradle 5.6 und höher diese Antwort .

In Projekt B müssen Sie nur eine testCompileAbhängigkeit hinzufügen :

dependencies {
  ...
  testCompile project(':A').sourceSets.test.output
}

Getestet mit Gradle 1.7.

Ein einfacher Weg ist das Hinzufügen einer expliziten Aufgabenabhängigkeit in ProjectB:

compileTestJava.dependsOn tasks.getByPath(':ProjectA:testClasses')

Eine schwierige (aber klarere) Möglichkeit besteht darin, eine zusätzliche Artefaktkonfiguration für ProjectA zu erstellen:

task myTestsJar(type: Jar) { 
  // pack whatever you need...
}

configurations {
  testArtifacts
}

artifacts {
   testArtifacts myTestsJar
}

und fügen Sie die testCompileAbhängigkeit für ProjectB hinzu

apply plugin: 'java'
dependencies {
  compile project(':ProjectA')
  testCompile project(path: ':ProjectA', configuration: 'testArtifacts')
}

Dies wird jetzt als erstklassiges Feature in Gradle unterstützt. Module mit javaoder java-libraryPlugins können auch ein java-test-fixturesPlugin enthalten, das Hilfsklassen und Ressourcen verfügbar macht, die mit testFixturesHelfer verbraucht werden sollen . Vorteile dieses Ansatzes gegenüber Artefakten und Klassifikatoren sind:

• ordnungsgemäßes Abhängigkeitsmanagement (Implementierung / API)
• schöne Trennung vom Testcode (separater Quellensatz)
• Testklassen müssen nicht herausgefiltert werden, um nur Dienstprogramme verfügbar zu machen
• gepflegt von Gradle

Beispiel

:modul:one

modul / one / build.gradle

plugins {
  id "java-library" // or "java"
  id "java-test-fixtures"
}

modul / one / src / testFixtures / java / com / example / Helper.java

package com.example;
public class Helper {}

:modul:other

modul / other / build.gradle

plugins {
  id "java" // or "java-library"
}
dependencies {
  testImplementation(testFixtures(project(":modul:one")))
}

modul / other / src / test / java / com / example / other / SomeTest.java

package com.example.other;
import com.example.Helper;
public class SomeTest {
  @Test void f() {
    new Helper(); // used from :modul:one's testFixtures
  }
}

Weiterführende Literatur

Weitere Informationen finden Sie in der Dokumentation:
https://docs.gradle.org/current/userguide/java_testing.html#sec:java_test_fixtures

Es wurde in 5.6 hinzugefügt:
https://docs.gradle.org/5.6/release-notes.html#test-fixtures-for-java-projects

Ich bin in letzter Zeit selbst auf dieses Problem gestoßen, und Mann, es ist schwierig, Antworten darauf zu finden.

Der Fehler, den Sie machen, besteht darin, dass ein Projekt seine Testelemente genauso exportieren sollte wie seine primären Artefakte und Abhängigkeiten.

Ich persönlich hatte viel mehr Erfolg damit, ein neues Projekt in Gradle zu machen. In Ihrem Beispiel würde ich es nennen

Projekt A_Test -> src / main / java

Ich würde die Dateien, die Sie derzeit in Projekt A / src / test / java haben, in src / main / java einfügen. Machen Sie alle testCompile-Abhängigkeiten Ihres Projekts A kompilieren Sie Abhängigkeiten von Project A_Test.

Machen Sie dann Projekt A_Test zu einer testCompile-Abhängigkeit von Projekt B.

Es ist nicht logisch, wenn man es aus der Sicht des Autors beider Projekte betrachtet, aber ich denke, es ist sehr sinnvoll, wenn man an Projekte wie junit und scalatest (und andere) denkt. Auch wenn diese Frameworks testbezogen sind, sind sie es werden nicht als Teil der "Test" -Ziele innerhalb ihrer eigenen Frameworks betrachtet - sie erzeugen primäre Artefakte, die andere Projekte zufällig in ihrer Testkonfiguration verwenden. Sie möchten nur demselben Muster folgen.

Der Versuch, die anderen hier aufgeführten Antworten zu geben, hat für mich persönlich nicht funktioniert (mit Gradle 1.9), aber ich habe festgestellt, dass das hier beschriebene Muster ohnehin eine sauberere Lösung ist.

Ich weiß, dass es eine alte Frage ist, aber ich hatte nur das gleiche Problem und verbrachte einige Zeit damit, herauszufinden, was los ist. Ich benutze Gradle 1.9. Alle Änderungen sollten in ProjectBs erfolgenbuild.gradle

So verwenden Sie Testklassen von ProjectA in Tests von ProjectB:

testCompile files(project(':ProjectA').sourceSets.test.output.classesDir)

So stellen Sie sicher, dass die sourceSetsEigenschaft für ProjectA verfügbar ist:

evaluationDependsOn(':ProjectA')

So stellen Sie sicher, dass Testklassen von ProjectA tatsächlich vorhanden sind, wenn Sie ProjectB kompilieren:

compileTestJava.dependsOn tasks.getByPath(':ProjectA:testClasses')

Neue testJar-basierte Lösung (Unterstützung für trnsitive Abhängigkeiten unterstützt) als Gradle-Plugin verfügbar:

https://github.com/hauner/gradle-plugins/tree/master/jartest

https://plugins.gradle.org/plugin/com.github.hauner.jarTest/1.0

Aus der Dokumentation

Wenn Sie einen Gradle-Build für mehrere Projekte haben, können Testabhängigkeiten zwischen Unterprojekten bestehen (was wahrscheinlich ein Hinweis darauf ist, dass Ihre Projekte nicht gut strukturiert sind).

Angenommen, ein Projekt, bei dem das Teilprojekt Projekt B von Projekt A abhängt und B nicht nur eine Kompilierungsabhängigkeit von A, sondern auch eine Testabhängigkeit aufweist. Um die Tests von B zu kompilieren und auszuführen, benötigen wir einige Testhelferklassen von A.

Standardmäßig erstellt gradle kein JAR-Artefakt aus der Testbuild-Ausgabe eines Projekts.

Dieses Plugin fügt eine testArchives-Konfiguration (basierend auf testCompile) und eine jarTest-Task hinzu, um ein jar aus dem Testquellensatz zu erstellen (wobei der Klassifizierertest dem Namen des jar hinzugefügt wird). Wir können uns dann in B auf die testArchives-Konfiguration von A verlassen (die auch die transitiven Abhängigkeiten von A enthält).

In A würden wir das Plugin zu build.gradle hinzufügen:

apply plugin: 'com.github.hauner.jarTest'

In B verweisen wir wie folgt auf die testArchives-Konfiguration:

dependencies {
    ...
    testCompile project (path: ':ProjectA', configuration: 'testArchives') 
}

Bitte lesen Sie das Update unten.

Ähnliche von JustACluelessNewbie beschriebene Probleme treten in IntelliJ IDEA auf. Das Problem ist, dass Abhängigkeit testCompile project(':core').sourceSets.test.outputtatsächlich bedeutet: "Abhängig von Klassen, die durch die Gradle-Build-Aufgabe generiert wurden". Wenn Sie also ein sauberes Projekt öffnen, in dem noch keine Klassen generiert wurden, erkennt IDEA sie nicht und meldet Fehler.

Um dieses Problem zu beheben, müssen Sie neben der Abhängigkeit von kompilierten Klassen eine Abhängigkeit von Testquelldateien hinzufügen.

// First dependency is for IDEA
testCompileOnly files { project(':core').sourceSets.test.java.srcDirs }
// Second is for Gradle
testCompile project(':core').sourceSets.test.output

Von IDEA erkannte Abhängigkeiten können Sie unter Moduleinstellungen -> Abhängigkeiten (Testumfang) beobachten .

Übrigens. Dies ist keine gute Lösung, daher ist Refactoring eine Überlegung wert. Gradle selbst hat ein spezielles Teilprojekt, das nur Testunterstützungsklassen enthält. Siehe https://docs.gradle.org/current/userguide/test_kit.html

Update 05.06.2016 Mehr Ich denke über Lösungsvorschläge nach, weniger gefällt es mir. Es gibt nur wenige Probleme damit:

1. Es werden zwei Abhängigkeiten in IDEA erstellt. Einer zeigt auf Testquellen, ein anderer auf kompilierte Klassen. Und es ist entscheidend, in welcher Reihenfolge diese Abhängigkeiten von IDEA erkannt werden. Sie können damit spielen, indem Sie die Abhängigkeitsreihenfolge unter Moduleinstellungen -> Registerkarte Abhängigkeiten ändern.
2. Durch das Deklarieren dieser Abhängigkeiten verschmutzen Sie die Abhängigkeitsstruktur unnötig.

Was ist die bessere Lösung? Meiner Meinung nach wird ein neuer benutzerdefinierter Quellensatz erstellt und freigegebene Klassen eingefügt. Tatsächlich haben die Autoren des Gradle-Projekts dazu den Quellensatz testFixtures erstellt.

Um es zu tun, müssen Sie nur:

1. Erstellen Sie einen Quellensatz und fügen Sie die erforderlichen Konfigurationen hinzu. Überprüfen Sie dieses im Gradle-Projekt verwendete Skript-Plugin: https://github.com/gradle/gradle/blob/v4.0.0/gradle/testFixtures.gradle

2. Deklarieren Sie die richtige Abhängigkeit im abhängigen Projekt:

   dependencies {
       testCompile project(path: ':module-with-shared-classes', configuration: 'testFixturesUsageCompile')
   }
   

3. Importieren Sie das Gradle-Projekt in IDEA und verwenden Sie beim Importieren die Option "Separates Modul pro Quellensatz erstellen".

Die Lösung von Fesler hat bei mir nicht funktioniert, als ich versucht habe, ein Android-Projekt (Gradle 2.2.0) zu erstellen. Also musste ich die erforderlichen Klassen manuell referenzieren:

android {
    sourceSets {
        androidTest {
            java.srcDir project(':A').file("src/androidTest/java")
        }
        test {
            java.srcDir project(':A').file("src/test/java")
        }
    }
}

Ich bin so spät zur Party (es ist jetzt Gradle v4.4), aber für alle anderen, die dies finden:

Angenommen:

~/allProjects
|
|-/ProjectA/module-a/src/test/java
|
|-/ProjectB/module-b/src/test/java

Gehen Sie zum build.gradle von Projekt B (das einige Testklassen von A benötigt) und fügen Sie Folgendes hinzu:

sourceSets {
    String sharedTestDir = "${projectDir}"+'/module-b/src/test/java'
    test {
        java.srcDir sharedTestDir
    }
}

oder (vorausgesetzt, Ihr Projekt heißt "ProjectB")

sourceSets {
    String sharedTestDir = project(':ProjectB').file("module-b/src/test/java")
    test {
        java.srcDir sharedTestDir
    }
}

Voila!

Wenn Sie Scheinabhängigkeiten haben, die Sie zwischen Tests teilen müssen, können Sie ein neues Projekt erstellen projectA-mockund es dann als Testabhängigkeit zu ProjectAund hinzufügen ProjectB:

dependencies {
  testCompile project(':projectA-mock')
}

Dies ist klare Lösung zu teilen Mock Abhängigkeiten, aber wenn Sie benötigen Tests aus laufen ProjectAin ProjectBGebrauch andere Lösung.

Wenn Sie Artefaktabhängigkeiten verwenden möchten, um Folgendes zu haben:

• Die Quellklassen von ProjectB hängen von den Quellklassen von Project A ab
• Die Testklassen von ProjectB hängen von den Testklassen von Project A ab

Dann sollte der Abschnitt mit den Abhängigkeiten von ProjectB in build.gradle ungefähr so aussehen:

dependencies {

  compile("com.example:projecta:1.0.0")

  testCompile("com.example:projecta:1.0.0:tests")

}

Damit dies funktioniert, muss ProjectA ein Test- JAR erstellen und es in die von ihm erzeugten Artefakte aufnehmen.

Das build.gradle von ProjectA sollte folgende Konfiguration enthalten:

task testsJar(type: Jar, dependsOn: testClasses) {
    classifier = 'tests'
    from sourceSets.test.output
}

configurations {
    tests
}

artifacts {
    tests testsJar
    archives testsJar
}

jar.finalizedBy(testsJar)

Wenn die Artefakte von ProjectA in Ihrem Artefakt veröffentlicht werden, enthalten sie ein Testglas .

Die testCompile im Abschnitt Abhängigkeiten von ProjectB bringt die Klassen in das -tests- JAR.

Wenn Sie die Quell- und Testklassen von Flat ProjectA zu Entwicklungszwecken in ProjectB aufnehmen möchten, sieht der Abschnitt mit den Abhängigkeiten in ProjectBs build.gradle folgendermaßen aus:

dependencies {

  compile project(':projecta')

  testCompile project(path: ':projecta', configuration: 'tests')

}

Einige der anderen Antworten verursachten auf die eine oder andere Weise Fehler - Gradle erkannte keine Testklassen aus anderen Projekten oder das Eclipse-Projekt hatte beim Import ungültige Abhängigkeiten. Wenn jemand das gleiche Problem hat, schlage ich vor:

testCompile project(':core')
testCompile files(project(':core').sourceSets.test.output.classesDir)

Die erste Zeile zwingt die Eclipse, das andere Projekt als Abhängigkeit zu verknüpfen, sodass alle Quellen enthalten und auf dem neuesten Stand sind. Mit der zweiten Option kann Gradle die Quellen tatsächlich anzeigen, ohne wie bisher ungültige Abhängigkeitsfehler zu verursachen testCompile project(':core').sourceSets.test.output.

Wenn Sie Kotlin DSL verwenden , sollten Sie Ihre Aufgabe gemäß der Gradle- Dokumentation so erstellen .

Wie bei einigen früheren Antworten müssen Sie innerhalb des Projekts eine spezielle Konfiguration erstellen, die die Testklasse gemeinsam nutzt, damit Sie Test- und Hauptklassen nicht mischen.

Einfache Schritte

1. In Projekt A müssten Sie Folgendes hinzufügen build.gradle.kts:

configurations {
    create("test")
}

tasks.register<Jar>("testArchive") {
    archiveBaseName.set("ProjectA-test")
    from(project.the<SourceSetContainer>()["test"].output)
}

artifacts {
    add("test", tasks["testArchive"])
}

2. Dann müssen Sie in Ihrem Projekt B in den Abhängigkeiten Folgendes hinzufügen build.gradle.kts:

dependencies {
    implementation(project(":ProjectA"))
    testImplementation(project(":ProjectA", "test"))
}

in Projekt B:

dependencies {
  testCompile project(':projectA').sourceSets.test.output
}

Scheint in 1.7-rc-2 zu funktionieren