Gradle review: pricing, pros, cons and setup

Gradle builds a directed graph of tasks from the build scripts and runs only what the requested task needs. The java plugin adds tasks such as compileJava, compileTestJava, test and check, wired together through their inputs and outputs, so ./gradlew test compiles exactly what the tests need and nothing else. Configuration happens first, when scripts are evaluated and the graph is built, then execution. That two-phase model is the source of both its speed and its learning curve: logic written at configuration time runs on every build, even when the task it configures is never executed, which is why the documentation pushes lazy configuration through providers and tasks.register.

Every task declares inputs and outputs. If they match the last run, the task is up to date and is skipped; with the build cache turned on, outputs can be restored from a previous build on this machine or a shared remote cache. The test task’s inputs include the compiled test and production classes, the runtime classpath and the task configuration, so tests rerun only when something they depend on changes. For unit tests that is a large saving. For suites that test a deployed environment, a database or a third-party API, the state that matters is outside Gradle’s view, so the task must be told to rerun, with --rerun on the command line or by modelling the environment as an input.

Tests run in JVMs forked from the build, isolated from Gradle’s own process. useJUnitPlatform selects the JUnit Platform, which runs JUnit Jupiter, Vintage, TestNG through its engine, Spock and others; useTestNG and useJUnit select the older runners. maxParallelForks, 1 by default, sets how many test JVMs run at once, and each has a unique org.gradle.test.worker system property for isolating files or ports. forkEvery recycles a JVM after a number of test classes, which contains leaky static state at the cost of speed. failFast stops at the first failure. Results are written as JUnit XML under build/test-results and an HTML report under build/reports/tests.

A long-lived daemon keeps build logic warm between runs, which is much of why repeated local builds are fast. The wrapper, gradlew with a properties file, downloads the Gradle version the repository names, so CI and every developer use the same one. Toolchains separate the Java that runs Gradle from the Java that compiles and runs tests: Gradle 9 needs Java 17 or later for the daemon, but a toolchain can still compile and test on another version, and Gradle 9.8 adds Java 27. Gradle can provision a missing toolchain if a resolver is configured.

Use the JVM Test Suite plugin rather than ad hoc Test tasks. Keep unit tests in the built-in test suite, and register suites such as apiTest and uiTest, each with its own dependencies, so Selenium or Playwright never sits on the unit test classpath. Order them with shouldRunAfter, and attach only fast suites to check, running the slow ones explicitly in CI. Put shared conventions, such as JUnit configuration, retries and report settings, in a convention plugin under build-logic so every module applies them identically. In a multi-project build, keep the automation framework code in its own project that the suites depend on.

Run through the wrapper, cache Gradle’s dependency and build caches, and publish JUnit XML whatever the outcome. In GitHub Actions the gradle/actions setup-gradle action configures caching and writes a job summary of each Gradle build, and wrapper-validation checks that the committed gradle-wrapper.jar is genuine. Pass --continue when several test tasks run, so one failing suite does not stop the others from reporting. Point the reporting step at build/test-results, which holds one folder per Test task.

Three settings do different jobs. maxParallelForks runs test classes in several JVMs within one Test task; give each fork its own resources using the org.gradle.test.worker property. org.gradle.parallel=true in gradle.properties runs tasks from different subprojects at the same time, so module suites overlap. The build cache, org.gradle.caching=true, avoids running unchanged suites at all. Begin with forks set to about half the CI machine’s cores for browser suites, measure, and raise it only if the environment under test keeps up. Across machines, Gradle Build Tool has no built-in sharding; split by subproject or test filter per CI job, or use Develocity Test Distribution.

Gradle 9.0 shipped on 31 July 2025, and 9.8 is the current minor. Upgrade on 8.14 first and clear every deprecation warning, then switch the wrapper. Expect four changes to matter for test projects: the daemon needs Java 17 or later, though toolchains can still test older targets; a Test task registered without testClassesDirs and classpath now runs no tests, silently, where it used to borrow the test source set; the test task fails when test sources exist but nothing is discovered; and the Conventions API is gone, which breaks older plugins and build scripts. Move to test suites and current plugin versions as part of the upgrade, and apply 9.8.1, which fixes three high-rated vulnerabilities.