Benefits

• Single codebase to maintain for listener, reporter, and launcher logic (previously 5 separate implementations)
• Consistent behavior across all test frameworks for filtering, parallel execution, and reporting
• Easier contributions — new features only need to be implemented once

Removed Providers

The following legacy provider modules have been removed:

• surefire-junit3
• surefire-junit4
• surefire-junit47
• surefire-testng

Only one provider module remains: surefire-junit-platform (the unified provider).

Minimum Version Requirements

• JUnit 3: No longer supported as a standalone dependency. JUnit 3 test code can still run, but requires a JUnit 4.12+ dependency on the classpath (the Vintage Engine handles the execution).
• JUnit 4 versions before 4.12 are no longer supported.
• TestNG versions before 6.14.3 are no longer supported.

Reimplemented Stack Trace Handling

Stack trace handling has been completely reimplemented as part of the provider unification. The previous per-provider implementations (LegacyPojoStackTraceWriter, JUnit4StackTraceWriter) have been replaced by a new StackTraceProvider and DefaultStackTraceWriter that work uniformly across all test frameworks. The new implementation includes configurable frame filtering and truncation.

Parameter Changes

These apply to both surefire:test and failsafe:integration-test unless noted otherwise.

Since 3.6.1 you get a warning when one of the ignored parameters is set. A legacy provider added as a plugin dependency still uses them (see Transitional: Using a Legacy Provider with 3.6.0 below).

Which parallel values still work:

• JUnit 4: classes, methods and classesAndMethods (or both). The number of threads comes from threadCount, or else the larger of threadCountClasses and threadCountMethods. suites, suitesAndClasses, suitesAndMethods and all aren't supported.
• TestNG: methods, classes, tests and instances, with threadCount. Before 3.6.1, tests and instances failed the build.
• JUnit 5/6: parallel isn't used. Use the Jupiter junit.jupiter.execution.parallel.* settings instead, see Using JUnit 5 Platform.

Run Order

alphabetical, reversealphabetical and random now sort the test methods inside each class too, not only the classes. This only applies to JUnit 5/6 tests. JUnit 4 and TestNG methods run in the same order as before.

A test that only passed because its methods ran in a certain order can now fail. This often happens with @TestInstance(PER_CLASS) classes that share state between methods.

To keep the JUnit default method order, either:

• add @TestMethodOrder to the class. Surefire never overrides it. If your methods depend on each other, this is the best fix: use @TestMethodOrder(MethodOrderer.OrderAnnotation.class) and put @Order on each method.
• or clear junit.jupiter.testmethod.order.default, the parameter Surefire sets, in configurationParameters. Classes are still sorted by runOrder.

<configuration>
    <runOrder>alphabetical</runOrder>
    <properties>
        <configurationParameters>
            junit.jupiter.testmethod.order.default=
        </configurationParameters>
    </properties>
</configuration>

With JUnit 6 you can also set it to org.junit.jupiter.api.MethodOrderer$Default.

Since 3.6.1, runOrder only sets the JUnit default class and method orderers that nobody else configured. An orderer set in configurationParameters, as a system property or in junit-platform.properties is kept. This includes one shipped by a library, like the class orderer Quarkus uses to group its tests by profile. In 3.6.0 the orderers from runOrder always won (#3529).

hourly was removed, and the build now fails with There's no RunOrder with the name hourly. It ran the tests alphabetically during even hours and in reverse during odd hours. Use random instead: the seed is printed in the build log, so you can replay a failing order with runOrderRandomSeed.

JUnit 5/6 Users

No changes needed. Your tests already run on the JUnit Platform natively.

JUnit 4 Users (4.12+)

No changes needed in most cases. Surefire automatically adds the Vintage Engine and routes your tests through the JUnit Platform. Verify your JUnit 4 dependency is version 4.12 or later:

<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.13.2</version>
    <scope>test</scope>
</dependency>

JUnit 3 Users

Add or update to a JUnit 4.12+ dependency. Your JUnit 3 test code will continue to run unchanged via the Vintage Engine:

<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.13.2</version>
    <scope>test</scope>
</dependency>

TestNG Users

Ensure your TestNG version is 6.14.3 or later. Surefire will automatically use the TestNG JUnit Platform Engine to execute your tests:

<dependency>
    <groupId>org.testng</groupId>
    <artifactId>testng</artifactId>
    <version>7.10.2</version>
    <scope>test</scope>
</dependency>

TestNG configuration (groups, listeners, reporters, parallel, etc.) continues to work through Surefire's plugin configuration and is mapped to the JUnit Platform infrastructure.

TestNG suite XML files (suiteXmlFiles) are no longer supported, and since 3.6.1 the build fails if they're set. Pick your tests with groups, includes/excludes or a JUnit Platform @Suite class instead. See Parameter Changes for the other parameters that changed.

Staying on Surefire 3.5.x

If you cannot update your test dependencies, you can stay on the 3.5.x line:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>3.5.5</version>
</plugin>

Transitional: Using a Legacy Provider with 3.6.0

As a transitional measure, you can add a legacy provider from the 3.5.x line as a plugin dependency:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>3.6.0</version>
    <dependencies>
        <dependency>
            <groupId>org.apache.maven.surefire</groupId>
            <artifactId>surefire-junit4</artifactId>
            <version>3.5.5</version>
        </dependency>
    </dependencies>
</plugin>

Note: this backward compatibility may not be maintained in future releases. TestNG suite XML files don't work this way either.