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 


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:


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


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:


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:


Then update the test:


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 


Add a new test:


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


3. Code Coverage

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


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:


Update the GradleRunner configuration in the CodeLinesPluginTest class:


Now, we can run tests and check coverage:


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:



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.


The Complete Gradle Plugin Tutorial.

Testing Gradle plugins (Gradle official guide).

Code lines counter plugin (Github).

Jacoco Gradle plugin.

Diff coverage plugin.

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