Przewodnik do testowania skryptów Gradle

Question

Jakie są najlepsze praktyki testowania skryptów Gradle?

Obecnie testuję jednostkowe skrypty ant z antunit, ale zamierzam przeprowadzić migrację do Gradle. Mogę tylko znaleźć artykuły na temat testowania kodu Java z Gradle lub Groovy, ale nic na temat testowania zadań Gradle, które tworzę lub testuję Groovy w ogóle. Czy istnieje odpowiednik antunit dla Gradle? Czy ktoś grał ze strukturą BDD (np. cucumber), aby przetestować skrypty Gradle?

Na przykład, obecnie mam następujące Ant docelowa

<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> 

Jak można sobie wyobrazić, jest to dość łatwe do złamania to gdy refactoring projektu, więc mam następujący antunit test, aby to sprawdzić.

<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> 

który nazywany jest przez następujący fragment produkować piękny raport xml

   <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> 

Rozumiem, jak migrować dist-bin do Gradle, ale nie jestem pewien, co jest właściwym sposobem migrować test-dist-bin i wywołanie au:antunit.

Answer 1

Gradle 3.x Test Toolkit dostępny! Proszę sprawdzić userguide tutaj: https://docs.gradle.org/current/userguide/test_kit.html

poprawności logiki może następnie zostać zweryfikowane przez stwierdzając, co następuje potencjalnie w połączeniu:

• wyjście kompilacji za;
• Rejestrowanie kompilacji (to jest wyjście konsoli);
• Zestaw zadań wykonywanych przez kompilację i ich wyniki (np. NIEPOWODZENIE, AKTUALIZACJA itp.).

kopiowaniem wklejony przykład:

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

Dopóki zastosujesz wtyczkę groovy, a testy będą wykonywane pod numerem src/test/groovy, nie trzeba wykonywać żadnej dodatkowej konfiguracji. To samo dotyczy testów BDD na przykład ze Spockiem. Jeśli chcesz przeczytać więcej na temat możliwości testowania Gradle, sprawdź książkę Building and Testing with Gradle. Obejmuje testowanie za pomocą JUnit, TestNG, Spock, Geb i EasyB.

Answer 3

Myślę, że Tom miał na myśli sposób na przetestowanie własnych zadań pisemnych, prawda? Jeśli napisałeś zadanie niestandardowe gradacji poprzez rozszerzenie DefaultTask i umieścisz je w folderze buildSrc projektu, możesz dodać klasę testową opartą na junit/spock/cokolwiek, aby przetestować implementację zadania. Konstrukcja własna Gradles stanowi dobry przykład. spojrzeć na

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

To jest specyfikacja Spock, który testuje ExtractDslMetaDataTask który został specjalnie napisany dla Griddles własnej kompilacji. ExtractDslMetaDataTask znajduje się pod adresem:

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

Aby dodać twierdzeń do budowania skryptów „zadań AdHoc”, jak swoim przykładzie powyżej można użyć Groovy twierdzenie zasilania.

przykład: jeśli masz aa bardzo proste zadanie takiego w swoim skrypcie:

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

można albo zmiany samego zadania, aby dodać twierdzenie:

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

lub dodasz dedykowane zadanie testowe do skryptu

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

pamiętaj, że yo możesz użyć pełnej mocy groovy języka w swoich skryptach budujących.

Istnieją plany, aby zintegrowany zestaw narzędzi do testowania był w gradle do wspierania autorów skryptów kompilacji w testowaniu ich niestandardowej logiki budowania. rzucić okiem na:

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