Come aggiungo un nuovo set di sorgenti a Gradle?

Voglio aggiungere test di integrazione alla mia build Gradle (versione 1.0). Dovrebbero essere eseguiti separatamente dai miei normali test perché richiedono una webapp da distribuire su localhost (testano quella webapp). I test dovrebbero essere in grado di utilizzare le classi definite nel mio set di sorgenti principale. Come posso farlo accadere?

Mi ci è voluto un po 'per capirlo e le risorse online non erano eccezionali. Quindi ho voluto documentare la mia soluzione.

Questo è un semplice script di build gradle che ha un set di sorgenti intTest oltre ai set di sorgenti principale e di test:

apply plugin: "java"

sourceSets {
    // Note that just declaring this sourceset creates two configurations.
    intTest {
        java {
            compileClasspath += main.output
            runtimeClasspath += main.output
        }
    }
}

configurations {
    intTestCompile.extendsFrom testCompile
    intTestRuntime.extendsFrom testRuntime
}

task intTest(type:Test){
    description = "Run integration tests (located in src/intTest/...)."
    testClassesDir = project.sourceSets.intTest.output.classesDir
    classpath = project.sourceSets.intTest.runtimeClasspath
}

Ecco come ho ottenuto questo risultato senza utilizzare configurations{ }.

apply plugin: 'java'

sourceCompatibility = JavaVersion.VERSION_1_6

sourceSets {
    integrationTest {
        java {
            srcDir 'src/integrationtest/java'
        }
        resources {
            srcDir 'src/integrationtest/resources'
        }
        compileClasspath += sourceSets.main.runtimeClasspath
    }
}

task integrationTest(type: Test) {
    description = "Runs Integration Tests"
    testClassesDir = sourceSets.integrationTest.output.classesDir
    classpath += sourceSets.integrationTest.runtimeClasspath
}

Testato utilizzando: Gradle 1.4 e Gradle 1.6

Questo è stato scritto una volta per Gradle 2.x / 3.x nel 2016 ed è di gran lunga obsoleto !! Dai un'occhiata alle soluzioni documentate in Gradle 4 e versioni successive

Per riassumere entrambe le vecchie risposte (ottieni la migliore e la minima praticabile di entrambi i mondi):

prima alcune parole calde:

1. per prima cosa, dobbiamo definire sourceSet:

   sourceSets {
       integrationTest
   }
   

2. successivamente espandiamo il sourceSetfrom test, quindi usiamo il test.runtimeClasspath(che include tutte le dipendenze da testAND teststesso) come classpath per il derivato sourceSet:

   sourceSets {
       integrationTest {
           compileClasspath += sourceSets.test.runtimeClasspath
           runtimeClasspath += sourceSets.test.runtimeClasspath // ***)
       }
   }
   

   • nota ) in qualche modo questa ridichiarazione / estensione per sourceSets.integrationTest.runtimeClasspathè necessaria, ma dovrebbe essere irrilevante poiché runtimeClasspathsi espande sempre output + runtimeSourceSet, non capirlo

3. definiamo un'attività dedicata solo per l'esecuzione dei test di integrazione:

   task integrationTest(type: Test) {
   }
   

4. Configurare l' integrationTestuso delle classi di test e dei percorsi di classe. Le impostazioni predefinite del javaplug-in utilizzano l'estensionetest sourceSet

   task integrationTest(type: Test) {
       testClassesDir = sourceSets.integrationTest.output.classesDir
       classpath = sourceSets.integrationTest.runtimeClasspath
   }
   

5. (opzionale) esecuzione automatica dopo il test

   integrationTest.dependsOn test
   

6. (opzionale) aggiungi dipendenza da check(quindi viene sempre eseguito quando buildo checkvengono eseguiti)

   tasks.check.dependsOn(tasks.integrationTest)

7. (opzionale) aggiungi java, risorse a sourceSetper supportare il rilevamento automatico e crea questi "parziali" nel tuo IDE. cioè IntelliJ IDEA creerà automaticamente le sourceSetdirectory java e le risorse per ogni set se non esiste:

   sourceSets {
        integrationTest {
            java
            resources
        }
   }
   

tl; dr

apply plugin: 'java'

// apply the runtimeClasspath from "test" sourceSet to the new one
// to include any needed assets: test, main, test-dependencies and main-dependencies
sourceSets {
    integrationTest {
        // not necessary but nice for IDEa's
        java
        resources

        compileClasspath += sourceSets.test.runtimeClasspath
        // somehow this redeclaration is needed, but should be irrelevant
        // since runtimeClasspath always expands compileClasspath
        runtimeClasspath += sourceSets.test.runtimeClasspath
    }
}

// define custom test task for running integration tests
task integrationTest(type: Test) {
    testClassesDir = sourceSets.integrationTest.output.classesDir
    classpath = sourceSets.integrationTest.runtimeClasspath
}
tasks.integrationTest.dependsOn(tasks.test)

riferito a:

• gradle java capitolo 45.7.1. Proprietà del set di origine
• gradle java capitolo 45.7.3. Alcuni esempi di set di sorgenti

Sfortunatamente, il codice di esempio su github.com/gradle/gradle/subprojects/docs/src/samples/java/customizedLayout/build.gradle o … / gradle /… / withIntegrationTests / build.gradle sembra non gestirlo o ha una differenza / più complesso / per me comunque nessuna soluzione più chiara!

Il plugin nebula-facet elimina il boilerplate:

apply plugin: 'nebula.facet'
facets {
    integrationTest {
        parentSourceSet = 'test'
    }
}

Per i test di integrazione in particolare, anche questo è fatto per te , basta applicare:

apply plugin: 'nebula.integtest'

I collegamenti al portale del plugin Gradle per ciascuno sono:

1. nebula.facet
2. nebula.integtest

Se stai usando

• Gradle 5.x, dai un'occhiata alla sezione Documentazione "Test di Java> Configurazione dei test di integrazione Esempio 14 e 15 per i dettagli (sia per Groovy che per Kotlin DSL, o quello che preferisci)
  
  • alt: link "corrente" al documento Gradle a 2 , ma potrebbe differire in futuro, dovresti dare un'occhiata se gli esempi cambiano)
• per Gradle 4 dai un'occhiata alla versione antica 3 che è vicina a quella che @Spina ha pubblicato nel 2012

Per fare in modo che IntelliJ riconosca il set di sorgenti personalizzato come root delle sorgenti di test:

plugin {
    idea
}

idea {
    module {
        testSourceDirs = testSourceDirs + sourceSets["intTest"].allJava.srcDirs
        testResourceDirs = testResourceDirs + sourceSets["intTest"].resources.srcDirs
    }
}

Ecco cosa funziona per me a partire da Gradle 4.0.

sourceSets {
  integrationTest {
    compileClasspath += sourceSets.test.compileClasspath
    runtimeClasspath += sourceSets.test.runtimeClasspath
  }
}

task integrationTest(type: Test) {
  description = "Runs the integration tests."
  group = 'verification'
  testClassesDirs = sourceSets.integrationTest.output.classesDirs
  classpath = sourceSets.integrationTest.runtimeClasspath
}

A partire dalla versione 4.0, Gradle ora utilizza directory di classi separate per ogni lingua in un set di sorgenti. Quindi, se il tuo script di build utilizza sourceSets.integrationTest.output.classesDir, vedrai il seguente avviso di deprecazione.

Gradle ora utilizza directory di output separate per ogni linguaggio JVM, ma questa build presuppone una singola directory per tutte le classi da un set di origini. Questo comportamento è stato deprecato ed è pianificato per essere rimosso in Gradle 5.0

Per eliminare questo avviso, passa sourceSets.integrationTest.output.classesDirsinvece a. Per ulteriori informazioni, vedere le note sulla versione di Gradle 4.0 .

Sono nuovo di Gradle, utilizzo Gradle 6.0.1 JUnit 4.12. Ecco cosa ho pensato per risolvere questo problema.

apply plugin: 'java'
repositories { jcenter() }

dependencies {
    testImplementation 'junit:junit:4.12'
}

sourceSets {
  main {
    java {
       srcDirs = ['src']
    }
  }
  test {
    java {
      srcDirs = ['tests']
    }
  }
}

Si noti che la fonte principale e la fonte di test sono referenziate separatamente, una sotto maine una sotto test.

L' testImplementationelemento sotto dependenciesviene utilizzato solo per compilare il sorgente in test. Se il tuo codice principale avesse effettivamente una dipendenza da JUnit, dovresti anche specificare implementationsotto dependencies.

Ho dovuto specificare la repositoriessezione per farlo funzionare, dubito che sia il migliore / unico modo.