{{announcement.body}}
{{announcement.title}}

How to Test Gradle Plugins

DZone 's Guide to

How to Test Gradle Plugins

See one dev's experience with creating functional tests for a custom Gradle plugin and how to configure the plugin to collect code coverage metrics.

· Java Zone ·
Free Resource

In this article, I share my experience of creating functional tests for a custom Gradle plugin and how to configure the plugin project to collect code coverage metrics from tests.

In the previous article, I described how to build a custom Gradle plugin. Here, we will continue to work with it. Before we start, I’d recommend recapping things in the previous article to get a better understanding of where we started.

Gradle unit test

0. Clone the Project 

Shell
 




x


 
1
git clone -b chapter-1 https://github.com/SurpSG/code-lines-counter-gradle-plugin.git



1. Configuration

Create a separate source set that will contain functional tests. Start with the creation of a simple directory, src/funcTests/kotlin.

Project file structureAfter creation, the directory looks like a usual folder, and it's not recognized as a code source by the IDE.

It's time to explain to Gradle that this directory will contain a code or in other words make it a 'sourceSet'

Open the 'build.gradle' file in the root of the project, add a new source set configuration, and reimport the project:

Groovy


Create a Gradle task that will run functional tests and add a Kotlin std lib dependency for the test configuration:

Groovy


2. Tests Creation

You can use any testing framework you like. In this example, I use JUnit 4.12. Create com.github.CodeLinesPluginTest Kotlin class:

Kotlin
 




xxxxxxxxxx
1
31


 
1
class CodeLinesPluginTest {
2
 
          
3
    // creates temp directory for a gradle project                      <-------- (1)
4
    @get:Rule
5
    var testProjectDir = TemporaryFolder()
6
 
          
7
    private lateinit var buildFile: File
8
    private lateinit var gradleRunner: GradleRunner
9
 
          
10
    @Before
11
    fun setup() {
12
        // creates empty build.gradle file in the test gradle project   <-------- (2)
13
        buildFile = testProjectDir.newFile("build.gradle")
14
 
          
15
        // creates and configures gradle runner                         <-------- (3)
16
        gradleRunner = GradleRunner.create()
17
            .withPluginClasspath()
18
            .withProjectDir(testProjectDir.root)
19
            .withTestKitDir(testProjectDir.newFolder())
20
    }
21
 
          
22
    @Test
23
    fun `check test setup`() {
24
        // runs `tasks` gradle task                                     <-------- (4)
25
        val result = gradleRunner
26
            .withArguments("tasks")
27
            .build()
28
 
          
29
        println(result.output)
30
    }
31
}



It is a simple functional test in the example above. The test creates a Gradle project and runs `tasks` Gradle task. Let's explore the test step by step:

  1. Declare the rule that cares about temporary directory creation. The directory is used as the project root.
  2. Create an empty build.gradle file in the project's root directory.
  3. Create a Gradle Runner that will help us to set up/build/run a test Gradle project.
  4. Execute the Gradle task, `tasks`. The Gradle Runner returns the execution result that is used for assertions.

Run the test and observe that basic Gradle tasks are printed to the console. We've just checked that our configuration is correct.

Apply the 'code-lines' plugin:

Kotlin
 




xxxxxxxxxx
1
15


 
1
@Before
2
fun setup() {
3
    buildFile = testProjectDir.newFile("build.gradle")
4
  
5
    // add common configuration for all tests in this class
6
    buildFile.appendText("""
7
        plugins {
8
            id 'java'                      // `code-lines` plugin is dependent on `java` plugin
9
            id 'com.github.code-lines'
10
        }
11
    
12
    """.trimIndent())
13
   
14
    ...
15
}



Then update the test:

Kotlin
 




xxxxxxxxxx
1


 
1
@Test
2
fun `codeLines task should print '0' when there is no source code`() {
3
    val result = gradleRunner
4
        .withArguments("codeLines")                             // <------- (1)
5
        .build()
6
 
          
7
    assertEquals(SUCCESS, result.task(":codeLines")!!.outcome)  // <------- (2)
8
    assertTrue(result.output.contains("Total lines: 0"))        // <------- (3)
9
}



Now, the test does the following steps:

  1. Invokes the codeLines task.
  2. Verifies codeLines' execution status.
  3. Verifies the output contains an expected message. The result is "Total lines: 0" because the test project doesn't have any code.

It's the simplest happy path test for the plugin. Let's add another one:

  1. Add a Java class to verify the plugin counts lines properly.
  2. Apply the non-default plugin's configuration.

Create a simple Java class by location code-lines-counter-gradle-plugin/src/funcTests/resources/TestClass.java 

Java
 




xxxxxxxxxx
1


 
1
public class TestClass {
2
 
          
3
    public static void main(String[] args) {
4
        System.out.println("Hello world");
5
    }
6
}



Add a new test:

Kotlin
 




xxxxxxxxxx
1
16


 
1
@Test
2
fun `codeLines task should print 'Total lines 6'`() {
3
    // creates folders in the temp project
4
    val testClassLocation: File = testProjectDir.newFolder("src", "main", "java").resolve("TestClass.java")
5
  
6
    CodeLinesPluginTest::class.java.classLoader
7
        .getResource("TestClass.java")!!.file.let(::File)
8
        .copyTo(testClassLocation)  // copies test file from resources to test project 
9
 
          
10
    val result = gradleRunner
11
        .withArguments("codeLines")
12
        .build()
13
 
          
14
    assertEquals(SUCCESS, result.task(":codeLines")!!.outcome)
15
    assertTrue(result.output.contains("Total lines: 6"))
16
}



Add one more test to check the plugin's configuration:

Kotlin
 




xxxxxxxxxx
1
21


 
1
@Test
2
fun `codeLines should skip blank lines`() {
3
    val testClassLocation: File = testProjectDir.newFolder("src", "main", "java").resolve("TestClass.java")
4
    CodeLinesPluginTest::class.java.classLoader
5
        .getResource("TestClass.java")!!.file.let(::File)
6
        .copyTo(testClassLocation)
7
 
          
8
    // apply `code-lines` plugin configuration
9
    buildFile.appendText("""
10
        codeLinesStat {
11
            sourceFilters.skipBlankLines = true 
12
        }
13
    """.trimIndent())
14
 
          
15
    val result = gradleRunner
16
        .withArguments("codeLines")
17
        .build()
18
 
          
19
    assertEquals(SUCCESS, result.task(":codeLines")!!.outcome)
20
    assertTrue(result.output.contains("Total lines: 5"))
21
}



3. Code Coverage

Apply the Jacoco plugin. Open build.gradle and update it with:

Groovy
 




xxxxxxxxxx
1
12


 
1
plugins {  
2
    id 'jacoco'
3
}
4
 
          
5
jacocoTestReport {
6
    reports.html.enabled = true
7
    executionData.setFrom fileTree(buildDir).include("/jacoco/*.exec")  // <------ (1) 
8
}
9
 
          
10
jacoco {
11
    toolVersion = '0.8.5'     // <----- (2)
12
}



Specify what coverage data files to analyze. As we have two separate test source sets, we need to tell Jacoco about it. Set Jacoco version. I prefer the latest version, especially if I'm using Kotlin.

At this step, we should add some extra configuration. Tests executed with the TestKit are run in daemon JVM. That's why we need to tell daemon JVM to use the Jacoco Java agent.

Luckily, we can use Jacoco-gradle-testkit-plugin that helps us here:

Groovy
 




xxxxxxxxxx
1


 
1
plugins {
2
    id "pl.droidsonroids.jacoco.testkit" version "1.0.5"
3
}
4
 
          
5
functionalTest.dependsOn generateJacocoTestKitProperties
6
generateJacocoTestKitProperties.destinationFile = file("$buildDir.absolutePath/jacoco/functional.exec")



Update the GradleRunner configuration in the CodeLinesPluginTest class:

Kotlin
 




xxxxxxxxxx
1


 
1
gradleRunner = GradleRunner.create()
2
            .withPluginClasspath()
3
            .withProjectDir(testProjectDir.root)
4
            .withTestKitDir(testProjectDir.newFolder())
5
            .apply {
6
                // gradle testkit jacoco support
7
                File("./build/testkit/testkit-gradle.properties")
8
                    .copyTo(File(projectDir, "gradle.properties"))
9
            }            



Now, we can run tests and check coverage:

Shell
 




xxxxxxxxxx
1


 
1
gradlew check jacocoTestReport



Open {PROJECT-ROOT}/build/reports/jacoco/test/html/index.html in your favorite browser

Opening task in browser

There’s one more plugin I recommend to use for your project. DiffCoverage builds a coverage report based on new or modified code. It may help to keep a high percentage of code coverage.

Full Working Example

Follow by the link or clone the project:

Shell
 




xxxxxxxxxx
1


 
1
git clone -b chapter-2-testing https://github.com/SurpSG/code-lines-counter-gradle-plugin.git



Conclusions

Functional tests are important because they show you if your plugin works correctly. You can check your plugin, but don't overdo the creation of tests because they are very poor in terms of performance. Prefer common happy path scenarios, like checking a plugin's configuration, plugin's task lifecycle, interaction with other plugins.

Code coverage tools help to detect untested code, so potentially, you can find and fix defects before your code is committed. Don't fully rely on such tools because they cannot guarantee that all corner cases are covered. They just show you if a code was invoked on tests run.

References

The Complete Gradle Plugin Tutorial.

Testing Gradle plugins (Gradle official guide).

Code lines counter plugin (Github).

Jacoco Gradle plugin.

Diff coverage plugin.

Topics:
coverage, functional test, gradle, gradle plugins, jacoco, java, junit, kotlin, testing

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}