Guía para pruebas de scripts Gradle

Question

¿Cuáles son las mejores prácticas para probar Gradle Scripts?

Actualmente pruebo unitariamente mis scripts ant con antunit, pero estoy buscando migrar a Gradle. Solo puedo encontrar artículos sobre la prueba de código Java de Gradle o Groovy, pero nada sobre probar las tareas de Gradle que creo o pruebo Groovy en general. ¿Hay un equivalente de antunit para Gradle? ¿Alguien ha jugado con un marco de BDD (como cucumber) para probar los scripts de Gradle?

Por ejemplo, actualmente tienen la siguiente Ant Objetivo

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

Como se puede imaginar, es bastante fácil de romper este al refactorizar el proyecto, así que tengo la siguiente antunit prueba para comprobarlo.

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

que se llama por el siguiente fragmento de código para producir un buen informe 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> 

entiendo cómo migrar dist-bin a Gradle, pero no estoy seguro de lo que es la forma correcta para migrar test-dist-bin y la llamada au:antunit.

Answer 1

Gradle 3.x Kit de herramientas de prueba disponible! Por favor, echa un vistazo a userguide aquí: https://docs.gradle.org/current/userguide/test_kit.html

La corrección de la lógica continuación, se puede verificar mediante la afirmación de la siguiente, posiblemente en combinación:

• La producción de la construcción;
• Registro de compilación (es decir, salida de consola);
• Conjunto de tareas ejecutadas por la compilación y sus resultados (por ejemplo, FALLO, ACTUALIZADO, etc.).

copia-pegado ejemplo:

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

Siempre que aplique el complemento groovy y sus pruebas se encuentren en src/test/groovy, no se necesita configuración adicional para ejecutarlas. Lo mismo es cierto para las pruebas de BDD con Spock, por ejemplo. Si desea leer más sobre las capacidades de prueba de Gradle, consulte el libro Building and Testing with Gradle. Cubre las pruebas con JUnit, TestNG, Spock, Geb y EasyB.

Answer 3

Creo que lo que Tom quiere decir es una forma de probar sus propias tareas Gradle escritos, ¿verdad? Si ha escrito una tarea gradle personalizada extendiendo DefaultTask y la coloca en la carpeta buildSrc de su proyecto, puede agregar una clase de prueba basada en junit/spock/whatever para probar su implementación de tareas. La compilación propia de Gradles proporciona un buen ejemplo para eso. echar un vistazo a

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

Esta es una especificación Spock, que pone a prueba la ExtractDslMetaDataTask que fue escrito específicamente para planchas propia construcción. El ExtractDslMetaDataTask se encuentra en:

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

Para agregar afirmaciones a sus tareas Creación de un script "ad hoc" como el ejemplo anterior se puede utilizar la afirmación de poder maravilloso.

un ejemplo: si tiene aa tarea muy simple como esto en el script:

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

pueden o bien modificar la propia tarea de añadir una afirmación:

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

o añades una tarea de prueba dedicado a su script

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

recuerde que yo Puedes usar toda la potencia del lenguaje groovy en tus scripts de compilación.

Hay planes para tener un juego de herramientas de prueba integrado en gradle para ayudar a los autores de scripts de compilación a probar su lógica de compilación personalizada. echar un vistazo a:

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