TestNG

TestNG is a Java testing framework built for more than unit tests — its name (“Next Generation”) signals the extras: flexible configuration, data-driven tests, grouping, dependencies, and built-in parallelism. It’s the default runner in most Java + Selenium stacks.

Almost every test runner shares the same skeleton: lifecycle hooks, assertions, data-driven inputs, parallelism, and reporting. Learn TestNG and you can read JUnit 5, NUnit, and pytest at a glance.

• JUnit 5 (Java) — the closest cousin; same ideas, different annotation names.
• NUnit (C#) — your Playwright stack’s runner; near-identical concepts with C# attribute syntax.
• pytest (Python) — same capabilities via fixtures and decorators instead of annotations.

TestNG runs methods in a fixed order driven by annotations, scoped from the whole suite down to a single method.

public class LoginTest {
  @BeforeMethod public void setUp()    { driver = new ChromeDriver(); }
  @Test         public void canLogin() { /* ... */ }
  @AfterMethod  public void tearDown() { driver.quit(); }
}

• Hard assertion (Assert.assertEquals) — fails fast: the test stops at the first failed check.
• Soft assertion (SoftAssert) — collects all failures and reports them together when you call assertAll(); nothing fails until then.

Soft asserts shine when you want to validate several independent things in one test (e.g. five fields on a page) and see all the broken ones in one run.

SoftAssert soft = new SoftAssert();
soft.assertEquals(user.getName(), "Ada");
soft.assertEquals(user.getRole(), "admin");   // still runs even if name failed
soft.assertAll();                              // reports every failure now

Two ways to feed inputs into a test:

• @DataProvider — a method returning Object[][]; TestNG runs the test once per row. Best for in-code or computed datasets.
• @Parameters — inject simple values from testng.xml (e.g. a browser name or base URL).

@DataProvider(name = "logins")
public Object[][] logins() {
  return new Object[][] {
    { "ada@test.dev", true },
    { "bad@test.dev", false },
  };
}

@Test(dataProvider = "logins")
public void login(String email, boolean expected) {
  assertEquals(authService.login(email), expected);
}

• Groups — tag tests (@Test(groups = "smoke")) and run a subset from testng.xml or the CLI. Like JUnit 5 @Tag, NUnit [Category], pytest markers.
• Priority — @Test(priority = 1) orders tests (default 0); lower runs first.
• Dependencies — dependsOnMethods / dependsOnGroups skip a test if its prerequisite failed, rather than reporting a misleading second failure.

@Test(groups = "smoke")
public void createUser() { /* ... */ }

@Test(dependsOnMethods = "createUser")   // skipped if createUser fails
public void deleteUser() { /* ... */ }

The testng.xml suite file is TestNG’s control center — it selects classes/groups, injects parameters, and configures parallelism without touching code.

<suite name="regression" parallel="methods" thread-count="4">
  <test name="chrome">
    <parameter name="browser" value="chrome"/>
    <classes>
      <class name="tests.LoginTest"/>
    </classes>
  </test>
</suite>

• parallel="methods|tests|classes|instances" with thread-count sets the concurrency model.
• Parallel tests must be thread-safe — share no mutable state; in Selenium use a ThreadLocal<WebDriver> so each thread gets its own driver.

• Listeners — hook into the test lifecycle (ITestListener, IRetryAnalyzer) to add logging, screenshots on failure, or custom reporting.
• Retry — implement IRetryAnalyzer to re-run a failed test N times (use sparingly — masks real flakiness).
• Reporting — TestNG emits HTML/XML reports; teams usually layer Allure or ExtentReports on top for richer output.

public class ScreenshotOnFail implements ITestListener {
  @Override public void onTestFailure(ITestResult result) {
    captureScreenshot(result.getName());   // attach to report
  }
}
// register: @Listeners(ScreenshotOnFail.class) or in testng.xml

The cheat sheet — same concept, four dialects: