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
4. The Android Gradle Plugin
5. A third-party plugin or test integration

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(2, 1 + 1)
    }
}

This mixes:

• a JUnit 5 annotation: org.junit.jupiter.api.Test
• a JUnit 4 assertion class: org.junit.Assert

That mixing is not usually the reason for the deprecation warning, but it can make your setup more confusing.

A cleaner JUnit 5 version would be:

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

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

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

Example of a likely cause in older builds

Older Gradle scripts sometimes use deprecated configurations such as:

dependencies {
    testCompile "junit:junit:4.12"
}

This should be replaced with:

dependencies {
    testImplementation "junit:junit:4.12"
}

So when Gradle reports deprecated features, check your whole build for old configuration names and old plugins.

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.

4. JUnit discovers test classes

   • It finds CalculatorTest.
   • It sees the @Test annotation from JUnit 5.

5. The test method runs

   • 1 + 1 evaluates to 2.
   • assertEquals(2, 2) passes.

6. Build succeeds

   • If no deprecated APIs are used by Gradle scripts or plugins, there is no deprecation failure.

Where your warning fits in

If you see:

Deprecated Gradle features were used in this build

then the issue happens before or around task execution, usually during build configuration or plugin behavior. That is why the fix often involves:

• changing Gradle configuration
• updating plugin versions
• removing deprecated DSL usage
• using a supported JUnit 5 setup for your project type

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:

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

instead of mixing old and new styles unless there is a specific reason.

Validate Android support before adding JUnit 5

In Android codebases, teams check whether the current Android Gradle Plugin and test plugin support JUnit 5 for:

• local unit tests
• instrumentation tests
• both or neither

This avoids configuration that looks correct but is not actually supported by the toolchain.

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

• confirm your Android plugin version supports your test setup
• use a dedicated JUnit 5 Android plugin if needed
• or stay with JUnit 4 until the toolchain is updated

4. Mixing JUnit 4 and JUnit 5 unnecessarily

Broken or confusing setup:

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

This may work in some cases, but it makes debugging harder.

Cleaner version:

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

5. Ignoring old Gradle configuration names

Deprecated example:

dependencies {
    compile "com.example:mylib:1.0"
    testCompile "junit:junit:4.12"
}

Modern version:

dependencies {
    implementation "com.example:mylib:1.0"
    testImplementation "junit:junit:4.12"
}

6. Upgrading only the wrapper, but not related plugins

Changing only this:

distributionUrl=https\://services.gradle.org/distributions/gradle-4.7-all.zip

may not be enough.

You may also need compatible versions of:

• Android Gradle Plugin
• Kotlin Gradle Plugin
• test-related plugins

Build warning vs test failure

JUnit 4 vs JUnit 5

Gradle dependency configurations

Plain Java Gradle vs Android Gradle for 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
• unsupported JUnit 5 setup in older Android environments

Key rule

Adding test dependencies is not the same as configuring Gradle to run those tests.

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.