Posted on by & filed under Content - Highlights and Reviews, Programming & Development.

A guest post by Andrew Oberstar, a community contributor to Gradle and plugin author. You can find him at or

Gradle is a build automation tool, making use of Groovy to provide a powerful Domain Specific Language (DSL) to describe and instruct the behavior of your build. Gradle is most frequently associated with builds for JVM languages (with built in support for Java, Groovy, and Scala), though there has been a lot of work in adding C++ support.

If you’re not familiar with Gradle, I suggest you read their home page. Their model-oriented approach makes it trivial to configure a typical build, while still providing flexibility to provide logic for unique cases.

We assume the basic knowledge of Gradle in this post, and we cover how to break out your tests (JUnit, specifically) so they can be run as separate tasks.

Why Would I Separate My Tests?

After a while of writing automated tests for your project, it may become unweildy to run them all in the same task. Maybe you want to get your commit build under 5 minutes or break up your build pipeline. More generically, the common examples are:

  • Separating different classes of tests: e.g. unit, integration, functional, acceptance
  • Separating long-running from quick tests (these often align to the classes, e.g. unit tests should be short running)

Whatever your reasons, Gradle gives you multiple options for dealing with the situation. I’ll be discussing two in this post:

  1. Grouping different types of tests into different source sets, with different Test tasks.
  2. Using JUnit categories to mark tests of different classes and separate them into different Test tasks.

Source Sets

As you might be aware, Gradle’s java plugin provides two source sets by default: main and test. It also provides a SourceSetContainer that allows you to configure these source sets or, significantly for this post, add new source sets.

What is a source set?

A source set is a logical grouping of source code. It primarily describes:

  • Where the source code is located
  • The classpath required to compile this source
  • The classpath required to run this source

Notably, the JavaBasePlugin, which provides some of the underlying logic for the java plugin, will also automatically do two important things when you add a new source set:

  1. Create compile and runtime configurations for the source set.
    • These will be tied to the source set’s compile and runtime classpaths, allowing you to specify different dependencies for each source set.
  2. Create a compile task for the source set.
    • Again this will be automatically wired into the source set and its configurations.

By default, a new source set will look for its source under src// (e.g. src/integTest/java).


In our example project we have both unit and integration tests that we would like to keep and run separately.

Creating a Source Set

First, we’ll want to create the source set. Since the integration tests will likely be running against the main code, and may even use some classes from test, the new source set needs to have them added to its classpath. See the DSL reference for SourceSet for more information.

If you’re going to use the classes from test, you will also need its dependencies, so we’ll want to extend its corresponding configurations. The test configurations already extend main, so we’ll get those dependencies for free. See the DSL reference for Configuration for more information.

Creating a Test Task

Now that we have a source set that can be compiled, it’s time to set up a new Test task that uses it. See the DSL Reference for Test for more information.

Due to Gradle’s fancy dependency handling, it knows that integTest‘s runtimeClasspath needs the resolved dependencies and compiled outputs of all three source sets.

Complete Example


Separating tests into different source sets won’t always be the best option. If your tests don’t have a clear line between them or you have really granular requirements for separating them, the coding overhead of configuring new source sets could become prohibitive.

As of Gradle 1.6, you can reference JUnit @Category annotations in your Test task config to filter which test classes/methods are executed in the task. You should note this is an “incubating” feature, so it may change in future versions.

Writing Tests with Categories

We’ll need to take a slight divergence into JUnit examples to explain this feature. JUnit’s @Category annotation can be placed on either a class or test method declaration and needs to be passed on or more interface classes that will be marked on the tests.

I’ll start off by declaring a bunch of interface types to use as categories.

Now let’s throw them onto a couple tests:

Configuring a Test Task to Filter by Category

Let’s keep the default test task, but only run the fast tests:

We also want two new test tasks for the performance and database tests. Since the task will default to using the classes from the test source set, we don’t need any of the config you saw in the sections above.

Using the useJUnit(Closure) method, you get access to JUnit specific properties, which currently is just these category methods.

Complete Example

Here is build.gradle:

Now if we run these tests to verify, you can see that only the specified categories are included in each task:


Gradle’s rich domain model exposes a lot of ways to describe your project. As shown in this post, it can be used to articulate the separation between your types of tests, giving you flexibility to run these tests in separate CI jobs, or even just to run them in more granularity while developing on your own machine.

See below for some Gradle resources from Safari Books Online.

Read these titles on Safari Books Online

Not a subscriber? Sign up for a free trial.

Gradle Beyond the Basics is an advanced guide that provides the recipes, techniques, and syntax to help you master this build automation tool. With clear, concise explanations and lots of ready-to-use code examples, you’ll explore four discrete areas of Gradle functionality: file operations, custom Gradle plugins, build lifecycle hooks, and dependency management.
Building and Testing with Gradle shows you to us Gradle for building and testing software written in Java and other JVM languages. It covers transitioning to Gradle from Maven, integration with IDEs such as Eclipse, and more.
Gradle Effective Implementation Guide is a great introduction and reference for using Gradle. The Gradle build language is explained with hands on code and practical applications. You learn how to apply Gradle in your Java, Scala or Groovy projects, integrate with your favorite IDE and how to integrate with well-known continuous integration servers.

About the author

andrew Andrew Oberstar, a community contributor to Gradle and plugin author. You can find him at or

Tags: DSL, gradle, Groovy, java, JUnit, JVM, Scala, testing, tests,

Comments are closed.