How to Fix Deprecated Gradle Features Used in This Build for JUnit 5 and Android Gradle

By the end of this page, you will understand what the "Deprecated Gradle features were used in this build" message really means, why it often appears after adding JUnit 5 or upgrading Gradle, and how to diagnose whether the problem comes from your build script, a plugin, or an unsupported Android/JUnit 5 setup. You will also learn the practical steps for fixing or isolating the warning.

Gradle shows a deprecation warning when your build uses an old feature that still works for now but is scheduled to stop working in a future Gradle version.

In simple terms:

• Deprecated means "allowed for now, but should be replaced"
• Incompatible with Gradle 5.0 means the code or plugin uses behavior that Gradle plans to remove
• The warning does not always mean your test code is wrong
• It often means a build script, plugin, or dependency integration is outdated

In this kind of setup, the important idea is that JUnit dependencies alone do not automatically enable JUnit 5 test execution everywhere.

For a regular Gradle Java project, JUnit 5 usually needs:

test {
    useJUnitPlatform()
}

But in Android projects, JUnit 5 support has historically been more limited than in plain Java projects, especially in older Gradle and Android Gradle Plugin versions. That means you can add JUnit 5 libraries successfully, but the Android test task or plugin may still not know how to run them correctly.

This warning matters because real projects depend heavily on build tools. If your build relies on deprecated APIs:

• upgrades become risky
• CI pipelines may start failing later
• plugins may break after a Gradle update
• test execution may behave differently than expected

So the real skill is not just "fix this one error," but learning to identify which layer is responsible:

1. Your code
2. Your build.gradle configuration
3. The Gradle version

Think of Gradle as a factory manager.

• Your source code is the raw material.
• Your build.gradle file is the instruction sheet.
• Plugins are specialized machines added to the factory.
• Gradle itself is the building.

A deprecation warning is like the manager saying:

"One of your machines still works, but it uses an old connector that will be removed in the next building upgrade."

The important part is that the problem may not be in the product you are making. It may be in:

• the instruction sheet
• a machine you installed
• a machine that is too old for the newer building

That is why adding JUnit 5 dependencies can appear to "cause" the problem even if the actual issue is an old plugin or unsupported test configuration.

Core idea: dependencies vs test engine configuration

Adding JUnit 5 libraries and actually running JUnit 5 tests are related, but not the same thing.

Plain Gradle Java project

In a normal Java or Kotlin JVM project, a typical JUnit 5 setup looks like this:

dependencies {
    testImplementation "org.junit.jupiter:junit-jupiter-api:5.10.2"
    testRuntimeOnly "org.junit.jupiter:junit-jupiter-engine:5.10.2"
}

test {
    useJUnitPlatform()
}

This tells Gradle:

• use JUnit 5 APIs at compile time
• use the JUnit 5 engine at test runtime
• run tests through the JUnit Platform

Android project caveat

In Android projects, older toolchains often do not support JUnit 5 directly in the same way. You may need:

• a newer Android Gradle Plugin
• a JUnit 5 Android support plugin
• or fallback to JUnit 4 for local unit tests if the environment is old

Your test code

Your test class is Kotlin and mostly fine structurally:

import org.junit.Assert
import org.junit.jupiter.api.Test
import org.junit.jupiter.api.TestInstance

@TestInstance(TestInstance.Lifecycle.PER_CLASS)
class TestClass {

    @Test
    internal fun testName() {
        Assert.assertEquals(,  + )
    }
}

Example build flow

Consider this simplified Gradle setup:

plugins {
    id 'java'
}

dependencies {
    testImplementation "org.junit.jupiter:junit-jupiter-api:5.10.2"
    testRuntimeOnly "org.junit.jupiter:junit-jupiter-engine:5.10.2"
}

test {
    useJUnitPlatform()
}

And this test:

import org.junit.jupiter.api.Assertions.assertEquals
import org.junit.jupiter.api.Test

class CalculatorTest {
    @Test
    fun addsNumbers() {
        assertEquals(2, 1 + 1)
    }
}

What happens step by step

1. Gradle reads the build file

   • It loads plugins.
   • It reads dependencies.
   • It configures the test task.

2. Gradle resolves dependencies

   • It downloads the JUnit 5 API.
   • It downloads the JUnit 5 engine.

3. Gradle starts the test task

   • Because useJUnitPlatform() is configured, Gradle runs tests using the JUnit Platform.

Where this matters in real projects

1. Upgrading old Android apps

Teams often upgrade Gradle wrapper versions first, then discover that old plugins or test configurations are deprecated.

2. Adding JUnit 5 to existing projects

A codebase may already use JUnit 4. Adding JUnit 5 libraries without adjusting the build can create confusion about which engine runs which tests.

3. Continuous integration pipelines

A build may pass locally but fail in CI after a Gradle upgrade because CI uses stricter versions or warnings are treated as failures.

4. Multi-module projects

One module may be modern, while another still uses deprecated configurations like compile, testCompile, or outdated plugin APIs.

5. Plugin compatibility checks

The problem is often not your application code but a third-party plugin that has not been updated for newer Gradle versions.

How developers handle this in real codebases

Use --warning-mode all to find the real source

Developers run:

./gradlew build --warning-mode all

and then inspect the exact warning lines to find:

• the deprecated configuration name
• the plugin class producing the warning
• the task involved

Keep build logic modern

Common replacements include:

• compile → implementation
• testCompile → testImplementation
• androidTestCompile → androidTestImplementation

Use guard clauses in build migration

When upgrading, developers often change one layer at a time:

1. Gradle wrapper
2. Android Gradle Plugin
3. Kotlin plugin
4. test libraries
5. third-party plugins

This makes it easier to isolate the breaking piece.

Prefer consistent test frameworks

If a project mainly uses JUnit 5, developers usually also use JUnit 5 assertions:

1. Assuming the test code caused the Gradle deprecation warning

The warning usually comes from build configuration or plugins, not from a simple assertion.

Misleading assumption

@Test
fun testName() {
    Assert.assertEquals(2, 1 + 1)
}

This test itself is not typically the reason Gradle says deprecated features were used.

Better approach

Check:

• Gradle version
• Android Gradle Plugin version
• old dependency configurations
• third-party plugins

2. Adding JUnit 5 dependencies without enabling the platform

In plain JVM projects, this is incomplete:

dependencies {
    testImplementation "org.junit.jupiter:junit-jupiter-api:5.10.2"
    testRuntimeOnly "org.junit.jupiter:junit-jupiter-engine:5.10.2"
}

You also need:

test {
    useJUnitPlatform()
}

If you omit that, tests may not run as expected.

3. Using JUnit 5 syntax in an unsupported Android setup

In older Android Gradle environments, this may not work correctly even if dependencies resolve.

How to avoid it

Build warning vs test failure

JUnit 4 vs JUnit 5

Quick diagnosis checklist

• Run:

./gradlew build --warning-mode all

• Look for:
  • deprecated configuration names
  • old plugins
  • Android Gradle Plugin compatibility issues
  • missing useJUnitPlatform() in JVM projects

Minimal JUnit 5 setup for a JVM project

dependencies {
    testImplementation "org.junit.jupiter:junit-jupiter-api:5.10.2"
    testRuntimeOnly "org.junit.jupiter:junit-jupiter-engine:5.10.2"
}

test {
    useJUnitPlatform()
}

Cleaner Kotlin JUnit 5 test

import org.junit.jupiter.api.Assertions.assertEquals
import org.junit.jupiter.api.Test

class TestClass {
    @Test
    fun testName() {
        assertEquals(2, 1 + 1)
    }
}

Common causes of the warning

• old Gradle DSL such as compile or testCompile
• outdated Android Gradle Plugin
• outdated third-party Gradle plugin

Why does Gradle say deprecated features were used?

It means your build script or a plugin is using an old Gradle API or configuration that still works now but is planned for removal.

Does this warning mean my test code is wrong?

Usually no. The problem is more often in the build configuration, plugin versions, or unsupported toolchain setup.

Is useJUnitPlatform() required for JUnit 5?

Yes, in standard JVM Gradle projects. Without it, Gradle may not run JUnit 5 tests correctly.

Can I use JUnit 5 in Android projects?

Yes, but support depends on your Android Gradle Plugin version and the type of test. Older Android setups often need extra configuration or plugins.

Can I mix JUnit 4 and JUnit 5?

Yes, but it can make your setup harder to understand. Prefer one style unless you need both during migration.

Why did the project build before I added tests?

Because dependency resolution and compilation may work, but test execution can expose unsupported or deprecated build behavior.

Should I fix the warning by only upgrading Gradle?

Not always. You may also need to upgrade the Android plugin, Kotlin plugin, or other Gradle plugins to compatible versions.

• Gradle build lifecycle — helps you understand when configuration, dependency resolution, and task execution happen.
• JUnit 4 vs JUnit 5 — important for understanding annotation differences and migration issues.
• Android Gradle Plugin — often the real source of compatibility limits in Android builds.
• Gradle dependency configurations — useful for replacing deprecated names like compile and testCompile.
• Gradle wrapper — controls the Gradle version used by the project.
• Test runners and test engines — explains why adding a library is not enough to run tests.
• Kotlin unit testing — relevant because the example test class is written in Kotlin.