iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Set forkEvery = 1 on the Gradle Test task. Gradle will start a new test JVM for every test class, adding process-startup overhead. This is intentionally a poor performance setting, useful for demonstrating how test-process forking affects a run—not a recommended optimization.
Set Gradle to fork once per test class
Add the setting to the relevant Test task in your build script. Use the DSL that matches your project:
Kotlin DSL: build.gradle.kts
tasks.withType<Test>().configureEach {
forkEvery = 1
}Groovy DSL: build.gradle
tasks.withType(Test).configureEach {
forkEvery = 1
}Scope the configuration to the task or tasks you want to affect. In a multi-project build, apply it to the relevant subproject tasks or through a shared convention. Gradle’s Test API documents forkEvery as the maximum number of test classes run in one forked process.
Why this makes a test run slower
Gradle runs tests in a JVM separate from the build process. With forkEvery = 1, each test class gets a fresh test JVM; the JVM must be started again as Gradle moves to the next class. Gradle’s Test API describes this setting as “very expensive” because process restarts have a performance cost. The actual impact depends on the number and size of test classes and the machine; there is no universal slowdown percentage.
#1 Best Overall
forkEvery |
Process behavior | Practical effect |
|---|---|---|
0 (default) |
No class-count limit; Gradle reuses the test process across test classes. | Avoids per-class JVM startup overhead. |
1 |
Starts a new test process for every test class. | Adds repeated JVM startup overhead and gives each class a fresh process. |
N |
Restarts the process after N test classes. | Trades some process reuse for more frequent restarts. |
These values and their documented behavior are described in Gradle’s Test API. The setting controls the test JVM lifecycle; it does not select JUnit 5.
Keep JUnit 5 configuration separate
JUnit Jupiter tests run through the JUnit Platform. If the project has not already selected that platform for the test task, configure it separately:
tasks.withType<Test>().configureEach {
useJUnitPlatform()
forkEvery = 1
}useJUnitPlatform() selects the platform; forkEvery controls how often Gradle replaces the test process. Gradle’s Java testing guide covers both test execution and test-process configuration.
Recommended Free Tools
Do not confuse per-class restarts with parallel forks
forkEvery sets how many test classes Gradle runs before replacing a test process. maxParallelForks sets how many test processes may run at the same time. Gradle documents a default of 1 for maxParallelForks; increasing it may reduce elapsed time on a multicore machine, but tests must be isolated. Tests that share files, databases, or services can conflict and fail intermittently when run concurrently. See Gradle’s testing guide for details.
Rank #3
For real performance problems, find the slow tests instead
If the goal is to shorten a suite rather than slow it down, inspect test durations and the build timeline with a Build Scan. Gradle’s performance guide describes using Build Scan to identify slow tests and notes that JVM forks have overhead; setting forkEvery too low can increase test time. The same guide notes that Gradle generates HTML and JUnit XML test reports by default, and disabling reports can reduce overhead in large suites when you do not need them.
Quick Recap
Best Value
Rank #4
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
