DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Please enter at least three characters to search
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workkloads.

Secure your stack and shape the future! Help dev teams across the globe navigate their software supply chain security challenges.

Releasing software shouldn't be stressful or risky. Learn how to leverage progressive delivery techniques to ensure safer deployments.

Avoid machine learning mistakes and boost model performance! Discover key ML patterns, anti-patterns, data strategies, and more.

Related

  • Test Driven Development Using TestNG, Gradle
  • Creating a Web Project: Refactoring
  • Enhancing Testing Efficiency: Transitioning From Traditional Code Coverage to Code Change Coverage
  • Transitioning From Groovy to Kotlin for Gradle Android Projects

Trending

  • Failure Handling Mechanisms in Microservices and Their Importance
  • My LLM Journey as a Software Engineer Exploring a New Domain
  • Solid Testing Strategies for Salesforce Releases
  • Scaling InfluxDB for High-Volume Reporting With Continuous Queries (CQs)
  1. DZone
  2. Coding
  3. Languages
  4. How to Test Gradle Plugins

How to Test Gradle Plugins

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

By 
Sergii Gnatiuk user avatar
Sergii Gnatiuk
·
Updated Jul. 20, 21 · Tutorial
Likes (4)
Comment
Save
Tweet
Share
16.3K Views

Join the DZone community and get the full member experience.

Join For Free

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 structure screenshot.After 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
 




x


 
1
sourceSets {
2
    functionalTest { // declares a new sourceset
3
        // specifies code source dir
4
        kotlin.srcDir file('src/funcTests/kotlin') 
5
        // specifies resource dir
6
        resources.srcDir file('src/funcTests/resources') 
7
      
8
        // specifies dependencies to compile test classes
9
        compileClasspath += sourceSets.main.output + configurations.testRuntimeClasspath
10
      
11
        // specifies dependencies to run tests
12
        runtimeClasspath += output + compileClasspath
13
    }
14
}



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

Groovy
 




xxxxxxxxxx
1


 
1
task functionalTest(type: Test) {
2
    description = 'Runs the functional tests.'
3
    group = 'verification'
4
    testClassesDirs = sourceSets.functionalTest.output.classesDirs
5
    classpath = sourceSets.functionalTest.runtimeClasspath
6
}
7
check.dependsOn functionalTest



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 the "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
 
plugins {  
    id 'jacoco'
}

jacocoTestReport {
    reports.html.enabled = true
    executionData.setFrom fileTree(buildDir).include("/jacoco/*.exec")  // <------ (1) 
}

jacoco {
    toolVersion = '0.8.7'     // <----- (2)
}


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

At this step, we should add some extra configurations. 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
 
plugins {
    id "pl.droidsonroids.jacoco.testkit" version "1.0.8"
}

functionalTest.dependsOn generateJacocoTestKitProperties
jacocoTestKit {
    applyTo("functionalTestRuntimeOnly", tasks.named("functionalTest"))
}


Update the GradleRunner configuration in the CodeLinesPluginTest class:

Kotlin
 
gradleRunner = GradleRunner.create()
            .withPluginClasspath()
            .withProjectDir(testProjectDir.root)
            .withTestKitDir(testProjectDir.newFolder())
            .apply {
                // gradle testkit jacoco support
                javaClass.classLoader.getResourceAsStream("testkit-gradle.properties")?.use { inputStream ->
                    File(projectDir, "gradle.properties").outputStream().use { outputStream ->
                        inputStream.copyTo(outputStream)
                    }
                }
            }            


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

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


  • Testing Gradle plugins (Gradle official guide).
  • Code lines counter plugin (Github).
  • Jacoco Gradle plugin.
  • Diff coverage plugin.
Testing Gradle Kotlin (programming language) Code coverage

Opinions expressed by DZone contributors are their own.

Related

  • Test Driven Development Using TestNG, Gradle
  • Creating a Web Project: Refactoring
  • Enhancing Testing Efficiency: Transitioning From Traditional Code Coverage to Code Change Coverage
  • Transitioning From Groovy to Kotlin for Gradle Android Projects

Partner Resources

×

Comments
Oops! Something Went Wrong

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends:

Likes
There are no likes...yet! 👀
Be the first to like this post!
It looks like you're not logged in.
Sign in to see who liked this post!