Guida per il test degli script Gradle

Question

Quali sono le migliori pratiche per testare gli script Gradle?

Attualmente collaudo i miei script ant con antunit, ma sto cercando di migrare a Gradle. Posso trovare solo articoli su come testare il codice Java da Gradle o Groovy, ma niente sul test delle attività di Gradle che creo o testando Groovy in generale. Esiste un equivalente di antunit per Gradle? Qualcuno ha giocato con un framework BDD (come cucumber) per testare gli script Gradle?

Per esempio, ho attualmente hanno il seguente Ant target

<target name="dist-bin" depends="build" description="creates a zip distribution of the current build"> 
    <zip destfile="build/TIBant-bin.zip"> 
     <zipfileset dir="src/ant" includes="**" /> 
     <zipfileset dir="test" includes="**" prefix="test" /> 
     <zipfileset dir="build" includes="TIBant.jar" /> 
     <zipfileset dir="build" includes="TIBant-*.html" /> 
     <zipfileset dir="build/examples/XMLtoProperties" 
        includes="XMLtoProperties.html" 
        prefix="examples/XMLtoProperties" /> 
     <zipfileset dir="lib" includes="**" prefix="lib" /> 
     <zipfileset dir="src/xslt" includes="**" excludes="test/**,userguide.xslt" prefix="lib/xslt" /> 
     <zipfileset dir="." includes="copyright.html,LICENSE.txt" /> 
     <zipfileset dir="examples" 
        includes="**" 
        excludes="**/build/**,**/config/default.properties" 
        prefix="examples" /> 
    </zip> 
</target> 

Come si può immaginare, è abbastanza facile da rompere questo quando refactoring il progetto, in modo da avere il seguente antunit test per verificare esso.

<target name="test-dist-bin"> 
    <delete file="build/TIBant-bin.zip" /> 
    <au:assertFalse message="Bin dist still present"> 
     <available file="build/TIBant-bin.zip" /> 
    </au:assertFalse> 
    <antcall target="dist-bin" /> 
    <au:assertTrue message="Bin dist not created"> 
     <available file="build/TIBant-bin.zip" /> 
    </au:assertTrue> 
    <delete dir="build/testBinDist" /> 
    <au:assertFalse message="TestBinDist still present"> 
     <available file="build/testBinDist" /> 
    </au:assertFalse> 
    <mkdir dir="build/testBinDist" /> 
    <unzip src="build/TIBant-bin.zip" dest="build/testBinDist" /> 
    <au:assertFalse message="config dir present"> 
     <available file="build/testBinDist/config/default.properties" /> 
    </au:assertFalse> 
    <au:assertTrue message="Ant Macros missing"> 
     <available file="build/testBinDist/tibant.xml" /> 
    </au:assertTrue> 
    <au:assertTrue message="Engine Stopper Jar missing"> 
     <available file="build/testBinDist/TIBant.jar" /> 
    </au:assertTrue> 
    <au:assertTrue message="Ant-contrib-missing"> 
     <available file="build/testBinDist/lib/ant-contrib-1.0b3.jar" /> 
    </au:assertTrue> 
    <au:assertTrue message="ant-unit missing"> 
     <available file="build/testBinDist/lib/ant-antunit-1.2.jar" /> 
    </au:assertTrue> 
    <au:assertTrue message="Copyright missing"> 
     <available file="build/testBinDist/copyright.html" /> 
    </au:assertTrue> 
    <au:assertTrue message="License missing"> 
     <available file="build/testBinDist/LICENSE.txt" /> 
    </au:assertTrue> 
    <au:assertFalse message="Src present"> 
     <available file="build/testBinDist/src/java/org/windyroad/tibant/EngineStopper.jar" /> 
    </au:assertFalse> 
    <au:assertTrue message="example missing"> 
     <available file="build/testBinDist/examples/SimpleProject/src/bw/example/Build/example.archive" /> 
    </au:assertTrue> 
    <au:assertFalse message="example has build files"> 
     <available file="build/testBinDist/examples/SimpleProject/build/*" /> 
    </au:assertFalse> 
    <au:assertFalse message="example has default config file"> 
     <available file="build/testBinDist/examples/SimpleProject/config/default.properties" /> 
    </au:assertFalse> 
    <property name="doc.file" 
       location="build/testBinDist/TIBant-User-Guide.html" /> 
    <au:assertTrue message="doc missing: ${doc.file}"> 
     <available file="${doc.file}" /> 
    </au:assertTrue> 
    <au:assertTrue message="xslt missing"> 
     <available file="build/testBinDist/lib/xslt/configure-ear.xslt" /> 
    </au:assertTrue> 
    <subant target="run-quick-tests"> 
     <fileset dir="build/testBinDist" includes="build.xml" /> 
    </subant> 
</target> 

quale è invocato il seguente frammento di produrre una relazione xml bel

   <au:antunit failonerror="@{failonerror}"> 
        <propertyset> 
         <propertyref name="config.filename" /> 
        </propertyset> 
        <path> 
         <pathelement location="@{antunit}" /> 
        </path> 
        <au:plainlistener logLevel="info" /> 
        <au:xmllistener todir="build" loglevel="info" /> 
       </au:antunit> 

capisco come migrare dist-bin a Gradle, ma non sono sicuro di quello che è il modo giusto di migrare test-dist-bin e la chiamata au:antunit.

Answer 1

Gradle 3.x prova Toolkit disponibile! favore, controlla userguide qui: https://docs.gradle.org/current/userguide/test_kit.html

La correttezza della logica possono poi essere verificata affermando quanto segue, eventualmente combinate:

• uscita del build;
• Registrazione del build (ad esempio output della console);
• L'insieme di attività eseguite dalla compilazione e i relativi risultati (ad esempio FAILED, UP-to-DATE ecc.).

copia-incollato esempio:

import org.gradle.testkit.runner.BuildResult; 
import org.gradle.testkit.runner.GradleRunner; 
import org.junit.Before; 
import org.junit.Rule; 
import org.junit.Test; 
import org.junit.rules.TemporaryFolder; 

import java.io.BufferedWriter; 
import java.io.File; 
import java.io.FileWriter; 
import java.io.IOException; 
import java.util.Collections; 

import static org.junit.Assert.assertEquals; 
import static org.junit.Assert.assertTrue; 

import static org.gradle.testkit.runner.TaskOutcome.*; 

public class BuildLogicFunctionalTest { 
    @Rule public final TemporaryFolder testProjectDir = new TemporaryFolder(); 
    private File buildFile; 

    @Before 
    public void setup() throws IOException { 
     buildFile = testProjectDir.newFile("build.gradle"); 
    } 

    @Test 
    public void testHelloWorldTask() throws IOException { 
     String buildFileContent = "task helloWorld {" + 
            " doLast {" + 
            "  println 'Hello world!'" + 
            " }" + 
            "}"; 
     writeFile(buildFile, buildFileContent); 

     BuildResult result = GradleRunner.create() 
      .withProjectDir(testProjectDir.getRoot()) 
      .withArguments("helloWorld") 
      .build(); 

     assertTrue(result.getOutput().contains("Hello world!")); 
     assertEquals(result.task(":helloWorld").getOutcome(), SUCCESS); 
    } 

    private void writeFile(File destination, String content) throws IOException { 
     BufferedWriter output = null; 
     try { 
      output = new BufferedWriter(new FileWriter(destination)); 
      output.write(content); 
     } finally { 
      if (output != null) { 
       output.close(); 
      } 
     } 
    } 
} 

Answer 2

Fintanto che si applica il plug-in groovy ei test si trovano sotto src/test/groovy non è necessaria alcuna configurazione aggiuntiva per eseguirli. Lo stesso vale per i test BDD con Spock, ad esempio. Se vuoi saperne di più sulle capacità di test di Gradle, consulta il libro Building and Testing with Gradle. Copre i test con JUnit, TestNG, Spock, Geb e EasyB.

Answer 3

Penso che quello che Tom voleva dire era un modo per testare i suoi compiti di gradle scritti, giusto? Se hai scritto un'attività gradle personalizzata estendendo DefaultTask e la metti nella cartella buildSrc del tuo progetto, puoi aggiungere una classe di test basata su junit/spock/any per testare l'implementazione dell'attività. La build personale di Gradles ne è un buon esempio. dare un'occhiata a

https://github.com/gradle/gradle/blob/master/buildSrc/src/test/groovy/org/gradle/build/docs/dsl/source/ExtractDslMetaDataTaskTest.groovy

Questa è una specifica Spock, che mette alla prova l'ExtractDslMetaDataTask che è stato appositamente scritto per bistecchiere propria build. L'ExtractDslMetaDataTask si trova in:

https://github.com/gradle/gradle/blob/master/buildSrc/src/main/groovy/org/gradle/build/docs/dsl/source/ExtractDslMetaDataTask.groovy

Per aggiungere asserzioni per il vostro costruire script "compiti ad hoc" come il vostro esempio di cui sopra è possibile utilizzare l'affermazione di potenza groove.

un esempio: se avete aa molto semplice compito come questo nello script:

task writeFoo << { 
    file("$buildDir/foo.txt").text = "bar" 
} 

è possibile modificare l'attività stessa di aggiungere un'affermazione:

task writeFoo << { 
    file("$buildDir/foo.txt").text = "bar" 
    assert file("$buildDir/foo.txt).isFile() 
} 

o si aggiunge un compito di test dedicato al tuo script

task testWriteFoo(dependsOn: writeFoo) << { 
    assert file("$buildDir/foo.txt).isFile() 
    assert file("$buildDir/foo.txt).text == "bar" 
} 

ricordare che yo Puoi usare tutta la potenza del linguaggio groovy negli script di build.

Ci sono piani per avere un toolkit di test integrato in gradle per supportare gli autori di script di compilazione sulla verifica della loro logica di compilazione personalizzata. dare un'occhiata a:

http://forums.gradle.org/gradle/topics/testing_toolkit_for_custom_build_logic