Was ist TestNG?

Was ist TestNG?

TestNG ist ein Open-Source-Java-Test-Framework, 2004 von Cédric Beust geschaffen, um Lücken in JUnit 3 (das damals das dominante Java-Test-Framework war) zu addressieren. Der Name steht für "Test Next Generation". TestNG wurde nicht nur für Unit-Tests designed, sondern für die breitere Test-Pyramide: Integrationstests, End-to-End-Tests, UI-Tests mit Selenium und Performance-Tests. Während JUnit mit JUnit 5 (Jupiter) erheblich aufgeholt hat, bleibt TestNG die dominante Wahl für Selenium-basiertes UI-Testing und große Enterprise-Java-Test-Suites.

Wenn dein Team funktionale QA an Java-Anwendungen macht — besonders mit Selenium WebDriver, REST Assured oder ähnlichen Tools — ist die Chance hoch, dass du TestNG nutzt. Die Kombination TestNG + Selenium + Maven + Jenkins bleibt der kanonische Java-QA-Stack bei den meisten Enterprises.

Was TestNG bietet, das JUnit (ursprünglich) nicht hatte

Die ursprünglichen Differenzierer (manche jetzt von JUnit 5 erreicht):

• Annotation-getriebene Konfiguration — @Test, @BeforeMethod, @AfterClass, @DataProvider, @Listeners statt TestCase zu subclassen.
• Test-Gruppen — Tags Tests mit @Test(groups = {"smoke", "regression"}) und führe Untermengen via XML-Konfiguration aus. Grundlegend für geschichtete Test-Suites.
• Abhängige Tests — @Test(dependsOnMethods = "login") deklariert Ausführungsreihenfolge. Kontrovers (Unit-Tests sollten unabhängig sein), aber nützlich für End-to-End-Flows.
• Data Providers — parametrisierte Tests mit @DataProvider. Führe die gleiche Test-Methode mit N verschiedenen Inputs aus.
• Parallele Ausführung — auf mehreren Granularitäten (Suite, Test, Klasse, Methode), in testng.xml konfiguriert. Das Killer-Feature für langsame Selenium-Suites.
• XML-Test-Konfiguration — definiere Test-Suites deklarativ in XML. Führe verschiedene Test-Kombinationen ohne Recompilieren aus.
• Listener und Reporter — Erweiterungspunkte für Custom-Logging, Screenshots bei Fehler (Selenium) und Custom-HTML-Reports.

Die kanonische TestNG-Test-Klasse

import org.testng.annotations.*;
import static org.testng.Assert.*;

public class CalculatorTest {
    private Calculator calc;

    @BeforeMethod
    public void setUp() {
        calc = new Calculator();
    }

    @Test(groups = {"smoke"})
    public void shouldAddTwoNumbers() {
        assertEquals(calc.add(2, 3), 5);
    }

    @Test(dataProvider = "divisionData")
    public void shouldDivide(int a, int b, int expected) {
        assertEquals(calc.divide(a, b), expected);
    }

    @DataProvider
    public Object[][] divisionData() {
        return new Object[][] {
            {10, 2, 5},
            {20, 4, 5},
            {100, 10, 10}
        };
    }
}

TestNG vs. JUnit 5 (der ehrliche 2026-Vergleich)

Der pragmatische Aufruf: JUnit 5 für Unit-Tests, TestNG für End-to-End und Selenium. Beide in einem Projekt zu mischen ist okay.

TestNG und Selenium WebDriver

Der Grund, warum TestNG populär bleibt: Selenium-UI-Tests sind langsam, flaky und erfordern sorgfältige Orchestrierung. TestNG-Features, die das lösen:

• Parallele Browser-Ausführung. Führe 10 Chrome-Instanzen parallel gegen deine Test-Suite aus. Schneidet Wall-Clock-Zeit dramatisch.
• Retry-Analyzer. Implementiere IRetryAnalyzer, um fehlgeschlagene Tests N-mal automatisch zu retryen. Zähmt Flakiness in Selenium.
• Listener für Screenshots. Implementiere ITestListener.onTestFailure, um einen Screenshot zu capturen, wann immer ein Test fehlschlägt — nützlich zum Debuggen von UI-Flakes.
• Gruppen-basierte Runs. Führe Smoke-Tests bei jedem Commit aus, volle Regression nächtlich, alles via testng.xml gesteuert.
• BeforeSuite-Browser-Setup. Öffne WebDriver einmal pro Suite (nicht pro Test), um Browser-Startup-Kosten zu amortisieren.

Häufige TestNG-Fallen

• Inter-Test-Abhängigkeiten via geteiltem State. Tests, die alleine bestehen, aber in einer Suite fehlschlagen, teilen meist statische Felder. Jeder Test sollte unabhängig sein.
• Parallele-Ausführung-Race-Conditions. WebDriver-Instanzen pro Thread, nicht pro Klasse. Nutze ThreadLocal<WebDriver> oder Seleniums SeleniumGrid.
• Hardcoded Waits. Thread.sleep(5000) tötet Test-Geschwindigkeit. Nutze Seleniums WebDriverWait mit expliziten Bedingungen.
• testng.xml-Drift. XML-Konfiguration wächst unhandlich. Halte es einfach: definiere Gruppen, zeige auf Pakete, lass TestNG Tests entdecken.
• Über-Nutzung von dependsOnMethods. Lange Abhängigkeitsketten kreieren kaskadierende Fehlschläge. Ein Fehlschlag bricht 10 nachgelagerte Tests ab und versteckt das Originalsignal.
• Kein Retry-Budget. Flaky Tests für immer zu retryen, maskiert echte Bugs. Cap Retries bei 2-3 und untersuche alles, was konsistent retryt.

TestNG laufen lassen: von CLI zu CI

• Maven Surefire/Failsafe — Standard für TestNG in Maven-Projekten. mvn test führt Unit-Tests aus; mvn verify führt Integrationstests via Failsafe aus.
• Gradle — useTestNG() in Test-Konfig; sonst Standard.
• IntelliJ IDEA / Eclipse — Erstklassige TestNG-Unterstützung; rechtsklick auf jeden Test → Run.
• CI (Jenkins, GitHub Actions, GitLab) — invoziere via Maven/Gradle, archiviere testng-results.xml + Custom-HTML-Reports.
• Docker — häufiges Pattern für Selenium: Selenoid oder Selenium Grid in Docker, TestNG läuft in CI und trifft das Grid.

FAQ: TestNG

Sollte ich TestNG oder JUnit 5 für neue Projekte nutzen?

Für Unit-Tests in Greenfield-Projekten, JUnit 5 — es ist der Default in Spring Boot und den meisten modernen Java-Tooling. Für Selenium-lastige QA-Suites, TestNG — bessere parallele Ausführung und Ökosystem-Fit. Viele Projekte nutzen beide.

Wird TestNG noch aktiv gepflegt?

Ja. TestNG hatte eine große 7.x-Release-Linie (aktuell Stand 2026); aktive Pflege und Java-21+-Kompatibilität. Cédric Beust kämpft noch dafür.

Kann TestNG JUnit-Tests laufen lassen?

Ja. TestNG kann JUnit-Tests via junit="true" in testng.xml wrappen. Nützlich während gradueller Migrationen. JUnit 5 kann TestNG-Tests nicht direkt laufen lassen.

Wie führe ich TestNG-Tests parallel aus?

In testng.xml: <suite parallel="methods" thread-count="4">. Granularitäten: suite, tests, classes, methods, instances. Methods ist am feinkörnigsten, erfordert aber vollständig unabhängige Tests.

Was ist eine TestNG-"Group"?

Ein Tag auf einer Test-Methode. @Test(groups = {"smoke", "regression"}). Führe via testng.xml aus: <groups><run><include name="smoke"/></run></groups>. Lässt dich Test-Suites in Smoke (schnell) und Regression (langsam) splitten ohne separate Test-Klassen.

Was ist mit TestNG mit Spring Boot?

Nutze spring-test mit TestNG via @ContextConfiguration + AbstractTestNGSpringContextTests. Spring Boot defaultet zu JUnit 5; du kannst zu TestNG wechseln, indem du Dependencies ersetzt. Springs Docs decken beide ab.

Wie LoadFocus zu TestNG und Java-Lasttest steht

TestNG deckt funktionale Java-Tests ab; für Lasttest derselben Java-Anwendungen ist JMeter das kanonische Tool. LoadFocus-JMeter-Cloud-Testing führt deine bestehenden .jmx-Dateien im Maßstab über 25+ Regionen aus, ohne dass du JMeter-Infrastruktur managst. Nutze TestNG für funktionale Regression, JMeter für Kapazitäts-Validierung und API-Monitoring für Production-Observability.