What's New in JUnit 6: Features & Enhancements

What Is JUnit 6

JUnit 6 is the latest major version of the JUnit testing framework for Java, released on 30 September 2025. It requires Java 17, unifies module versioning, and adds native Kotlin coroutine support.

New to the framework? This JUnit tutorial covers the fundamentals before you dig into the JUnit 6 changes below.

The headline changes compared to JUnit 5 are:

• Java 17 baseline: The minimum runtime is now Java 17, up from Java 8 in JUnit 5.
• Unified versioning: Platform, Jupiter, and Vintage now share a single version number (6.0.0).
• Kotlin coroutine support: Test and lifecycle methods can now be declared as suspend functions.
• Cancellation API: Test execution can be cancelled mid-run through a CancellationToken.
• Removed legacy modules: Deprecated artifacts like junit-platform-runner and junit-platform-jfr are gone.

JUnit 6 Highlights

When I updated my first project to JUnit 6, the version table in the pom.xml was the most immediately visible change: one version number across all three modules instead of two.

Here is a quick overview of every major shift bundled into this release:

• The minimum Java version is raised to 17
• The minimum baseline for Kotlin is raised to 2.2
• Unified versioning across modules
• Removal of deprecated artifacts like junit-platform-runner and junit-platform-jfr
• Integration of Java Flight Recorder support directly into the platform launcher
• Adoption of JSpecify nullability annotations for better type safety
• Improved CSV parsing with the FastCSV library
• Launcher and Platform API improvements
• Introduction of fail-fast execution
• Nested class ordering improvements
• Method and class ordering inheritance

What Are the Major Changes and Enhancements in JUnit 6

JUnit 6 groups its changes into removals, deprecations, and module-level improvements. The removals carry the highest migration risk because they will cause compile errors, and those come first.

Deprecations and Removals in JUnit 6

JUnit 6 removes APIs and modules that were deprecated in JUnit 5, raises the Java and Kotlin baselines, and unifies version numbering, all of which require attention before upgrading.

Minimum Java and Kotlin Version Changes

JUnit 6 raises the minimum Java version to 17. The wider ecosystem has standardized on Java 17 as the new baseline, so the framework follows suit.

Projects still on earlier Java versions are not forced to upgrade: JUnit 5 remains supported for at least another year.

For Kotlin users, JUnit 6 raises the minimum version to 2.2 or later.

Unified Versioning Across JUnit Modules

JUnit 6 has three major architecture components:

• Platform: Acts as the underlying foundation that lets testing frameworks run and launch on the JVM.
• Jupiter: Brings together the programming and extension models used to write JUnit tests and extensions.
• Vintage: Lets JUnit 3 and JUnit 4 tests run on the platform through its TestEngine.

In JUnit 5, Jupiter and Vintage shared one version while the Platform used a different one. JUnit 6 simplifies this: all three components now share a single version number.

Module and Plugin Removals and Integrations

Several modules that were deprecated in JUnit 5 are fully removed in JUnit 6. If any of these appear in your build file, remove or replace them before upgrading:

• junit-platform-runner and junit-platform-jfr are gone, their capabilities folded into junit-platform-launcher.
• junit-jupiter-migrationsupport is no longer supported. Teams still on JUnit 4 should finish the JUnit 6 migration before upgrading.
• junit-platform-suite-commons is dropped; its functionality is built directly into junit-platform-suite.
• Maven Surefire and Failsafe versions below 3.0.0 are no longer supported.

Deprecations and Removals in the JUnit Platform Module

These deprecated APIs are gone in JUnit 6:

• ReflectionSupport.loadClass(String) method
• ReflectionUtils.readFieldValue(...) methods
• ReflectionUtils.getMethod(...) method
• BlacklistedExceptions class
• PreconditionViolationException class (from org.junit.platform.commons.util)
• ClasspathScanningSupport class
• ConfigurationParameters.size() method
• MethodSelector.getMethodParameterTypes() method
• NestedMethodSelector.getMethodParameterTypes() method
• ReportEntry() constructor
• SingleTestExecutor class
• LauncherDiscoveryRequestBuilder() constructor
• LegacyReportingUtils class
• TestPlan.add(TestIdentifier), TestPlan.getChildren(String), and TestPlan.getTestIdentifier(String) methods
• @UseTechnicalNames annotation for suites
• EngineTestKit.execute(String, EngineDiscoveryRequest), EngineTestKit.execute(TestEngine, EngineDiscoveryRequest), and EngineTestKit.Builder.filters(DiscoveryFilter...) methods

All getOrComputeIfAbsent(...) methods in NamespacedHierarchicalStore have been deprecated. Use the new computeIfAbsent(...) methods instead.

Deprecations and Removals in the JUnit Jupiter Module

Two configuration parameters that were long overdue for removal are finally gone:

• junit.jupiter.tempdir.scope
• junit.jupiter.params.arguments.conversion.locale.format

Jupiter also removes two components outright:

• MethodOrderer.Alphanumeric class
• InvocationInterceptor.interceptDynamicTest(Invocation, ExtensionContext) method

A few more Jupiter changes worth knowing before you upgrade:

• The JRE enum constants from JAVA_8 to JAVA_16 are deprecated; they cannot be used at runtime under the Java 17 baseline.
• The default min value for @EnabledForJreRange and @DisabledForJreRange is now JAVA_17.
• Updates to @CsvSource and @CsvFileSource include removing the lineSeparator attribute (now auto-detected) and disallowing any values that appear after closing quotes.

Deprecations and Removals in the JUnit Vintage Module

The JUnit Vintage test engine is now deprecated. If it detects at least one JUnit 4 test class, it logs an INFO-level discovery message.

This deprecation is clear: use Vintage only as a temporary bridge to execute JUnit4 tests with JUnit5 and JUnit 6 while you migrate to Jupiter or a framework that supports the JUnit Platform natively.

General Improvements to the JUnit Platform Module

The Platform module gains a more flexible launcher API, new class selectors, and a formal cancellation model. Most of these changes are invisible to test authors.

They matter to the tools that orchestrate test runs: IDEs, CI systems, and build plugins. I found the CancellationToken addition useful when wiring test runs into custom CI pipelines that need clean abort paths.

Here is what changed:

• Launcher.execute(LauncherExecutionRequest) and LauncherDiscoveryRequestBuilder.forExecution() give tools more control over how they configure and trigger a test run.
• Class selectors DiscoverySelectors.selectClasses(...) and selectClassesByName(...) make it easier to target specific classes without verbose selector boilerplate.
• A formal CancellationToken API lets IDEs and CI systems abort an in-progress run, instead of using thread interrupts or process kills.
• Pass --fail-fast to the ConsoleLauncher's execute subcommand to halt the suite on the first failure, useful for fast CI feedback.
• The @Suite engine also respects CancellationToken, so suite-level runs can be stopped cleanly mid-execution.
• Every JUnit module ships JSpecify nullability annotations, making it explicit which parameters, return types, and fields accept null values.

Specific Improvements to the JUnit Jupiter Module

Jupiter gains deterministic nested-class ordering, native Kotlin coroutine support, and cleaner parameterized-test output. These changes make test hierarchies more predictable and parameterized results easier to read.

• @Nested inherits the @TestMethodOrder configuration from its enclosing class, making ordering predictable without re-annotating every inner class.
• The execution order of @Nested inner classes is deterministic and respects ClassOrderer.Default and MethodOrderer.Default when no explicit order is set.
• Kotlin suspend functions work as test and lifecycle methods without a runBlocking wrapper, a long-requested feature for coroutine-heavy codebases.
• Parameterized test display names are standardized: arguments use a name = value format, strings are quoted, and special characters are escaped.
• @CsvSource and @CsvFileSource switched to the FastCSV library, which handles malformed CSV more consistently than the previous parser.
• The Arguments interface is officially marked @FunctionalInterface, enabling lambda-style argument suppliers.
• Reason strings in ConditionEvaluationResult are declared @Nullable, bringing the API in line with the JSpecify nullability annotations adopted across the whole framework.

How to Run Your JUnit 6 Tests at Scale

Once your suite is migrated, the next question is scale. Running JUnit 6 tests sequentially on a single machine limits coverage and slows CI feedback.

This is where a cloud grid pays off. Test automation platform by TestMu AI (Formerly LambdaTest) runs your existing JUnit 6 Selenium suite in parallel across 3,000+ real browser and OS combinations.

Because it speaks standard RemoteWebDriver, you point existing tests at the grid without rewriting them. Key capabilities that map directly to JUnit 6 workflows:

• AI Test Authoring: KaneAI authors tests in natural language and generates Selenium and Playwright code, runnable on Automation Cloud without extra configuration.
• HyperExecute Orchestration: HyperExecute distributes tests across parallel nodes, up to 70% faster than a standard Selenium Grid, retrying flaky tests automatically.
• Auto Healing: When a DOM change breaks a locator, the engine reformulates it from stored benchmarks. Enable via the autoHeal: true capability.
• SmartWait: Runs actionability checks so an element is visible, enabled, and stable before acting.
• Session Artifacts: Every run produces a video recording, network logs, console logs, and screenshots, available immediately with no additional setup.
• CI/CD Integration: Connects to Jenkins, GitHub Actions, GitLab CI, CircleCI, and 120+ other tools, triggering tests per pull request to gate deployments.

You can wire your existing JUnit 6 suite to the cloud grid by pointing your RemoteWebDriver at the TestMu AI hub. See the JUnit with Selenium documentation for the setup steps.

Conclusion

JUnit 6 is a modernization, not a rewrite. The Jupiter API you already know is unchanged, so most JUnit 5 suites move over by bumping versions, not editing tests.

Before upgrading, confirm the project runs on Java 17 and Kotlin 2.2, drop the removed modules, and raise Surefire and Failsafe to 3.0.0 or later.

Once the build is green, scale the suite on a cloud grid and keep the JUnit 6 migration guide handy for any JUnit 4 code still on Vintage.