JUnit and TestNG

Why it matters

JUnit is the assumed default across the Java ecosystem

Spring Boot's default test starter, Maven Surefire's out-of-the-box configuration, and most Java tutorials all assume JUnit (specifically the Jupiter engine) unless a project deliberately chooses otherwise.

TestNG's data-driven and parallel-execution features made it common in Selenium and functional suites

@DataProvider feeds a single test method many input rows natively, and a testng.xml suite file can configure parallel execution at the method, class, or suite level without any extra plugin.

The two aren't mixed inside one test class

They use different annotations and lifecycle names — @BeforeEach in JUnit versus @BeforeMethod in TestNG — so a codebase generally standardizes on one, and running both means maintaining two separate reporting and configuration setups in the same build.

Framework choice shapes what the CI pipeline actually reports

Maven Surefire and Failsafe produce slightly different report output depending on which engine ran, and IDE test-runner integration, along with reporting tools like Allure, plugs into each framework somewhat differently.

Where JUnit 5 (and now JUnit 6) stands today

import org.junit.jupiter.api.Test;
import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.CsvSource;
import static org.junit.jupiter.api.Assertions.assertEquals;

class CalculatorTest {
    @Test
    void addsTwoNumbers() {
        assertEquals(5, Calculator.add(2, 3));
    }

    @ParameterizedTest
    @CsvSource({"2,3,5", "10,-1,9", "0,0,0"})
    void addsVariousPairs(int a, int b, int expected) {
        assertEquals(expected, Calculator.add(a, b));
    }
}

TestNG's answer to the same problems

import org.testng.annotations.Test;
import org.testng.annotations.DataProvider;
import static org.testng.Assert.assertEquals;

public class CalculatorTest {
    @DataProvider(name = "pairs")
    public Object[][] pairs() {
        return new Object[][] { {2, 3, 5}, {10, -1, 9}, {0, 0, 0} };
    }

    @Test(dataProvider = "pairs")
    public void addsVariousPairs(int a, int b, int expected) {
        assertEquals(Calculator.add(a, b), expected);
    }
}

Parallel execution and test dependencies

What actually differs day to day

Mistakes people make here

Mixing JUnit 4 and JUnit 5 (Jupiter) annotations in the same class

@Before/@After (from org.junit, JUnit 4) and @BeforeEach/@AfterEach (from org.junit.jupiter.api, JUnit 5) look similar but come from different packages — using the JUnit 4 one in a class run by the Jupiter engine doesn't cause a compile error, it's just silently ignored, unless the deprecated Vintage engine is also on the classpath to interpret it.

Writing TestNG tests that rely on an implicit execution order

TestNG doesn't guarantee declaration-order execution any more than JUnit does — a test that depends on state a previous test happened to leave behind needs an explicit dependsOnMethods or dependsOnGroups declaration, not an assumption that TestNG will just run things in file order.

Treating a failing @DataProvider or @ParameterizedTest row as 'the test is flaky'

Both report each input set as its own separately named test invocation, so a single failing row is a specific, reproducible input — not intermittent flakiness — but CI summaries that collapse parametrized results into one line can make it look that way if nobody expands the detail.

Choosing TestNG for a new Selenium or integration suite purely out of habit, without checking what the rest of the project uses

Running both frameworks in one repository means maintaining two sets of Maven Surefire/Failsafe configuration, two IDE test-runner setups, and two reporting outputs for what is otherwise one test suite — a real, ongoing maintenance cost for a decision usually made once, early, without much thought.

Strengths and trade-offs

Who needs this

Any Java developer writing tests needs JUnit at minimum, since it's the ecosystem default; TestNG is worth knowing for teams maintaining older Selenium or functional suites, or that specifically need native test dependencies and data providers without adding extra libraries.

Questions about junit and testng

Should a new Java project pick JUnit or TestNG?

JUnit 5 (Jupiter) is the safer default today because of how deeply it's integrated with Spring Boot, build tools, and IDEs. TestNG remains a reasonable choice if a team specifically wants native test dependencies or data providers without extra libraries, or is already standardized on it for an existing Selenium suite.

Is JUnit 4 still relevant?

Existing JUnit 4 suites keep running via the Vintage engine on top of the modern JUnit Platform, but Vintage is explicitly deprecated and meant only as a temporary migration aid — new tests should be written against Jupiter (JUnit 5/6), not JUnit 4.

Can JUnit and TestNG run in the same Maven or Gradle build?

Technically yes, since both integrate with Surefire and Failsafe, but it means maintaining two separate reporting and configuration setups for what functions as one test suite — most projects standardize on a single framework rather than run both long-term.

What replaced JUnit 5 as the current version?

JUnit 6, released in September 2025, keeps the same Jupiter programming model most JUnit 5 code already uses, while unifying Platform, Jupiter, and Vintage under one shared version number and raising the minimum supported Java version to 17.

The primary source

• JUnit ↗
• JUnit User Guide ↗
• TestNG documentation ↗