Qu'est-ce que TestNG ?

Qu'est-ce que TestNG ?

TestNG est un framework de testing Java open-source créé par Cédric Beust en 2004 pour adresser les manques de JUnit 3 (qui était le framework de testing Java dominant à l'époque). Le nom signifie "Test Next Generation". TestNG a été conçu non seulement pour les tests unitaires mais pour la pyramide de tests plus large : tests d'intégration, tests end-to-end, tests UI avec Selenium et tests de performance. Bien que JUnit ait considérablement rattrapé avec JUnit 5 (Jupiter), TestNG reste le choix dominant pour le testing UI basé Selenium et les grandes suites de tests Java d'entreprise.

Si votre équipe fait du QA fonctionnel sur des applications Java — surtout avec Selenium WebDriver, REST Assured ou des outils similaires — il y a de fortes chances que vous utilisiez TestNG. La combinaison TestNG + Selenium + Maven + Jenkins reste le stack QA Java canonique dans la plupart des entreprises.

Ce que TestNG offre que JUnit n'avait pas (à l'origine)

Les différenciateurs originaux (certains maintenant rattrapés par JUnit 5) :

• Configuration pilotée par annotations — @Test, @BeforeMethod, @AfterClass, @DataProvider, @Listeners au lieu de sous-classer TestCase.
• Groupes de tests — taguez les tests avec @Test(groups = {"smoke", "regression"}) et exécutez des sous-ensembles via configuration XML. Fondamental pour des suites de tests stratifiées.
• Tests dépendants — @Test(dependsOnMethods = "login") déclare l'ordre d'exécution. Controversé (les tests unitaires devraient être indépendants) mais utile pour les flux end-to-end.
• Data providers — tests paramétrés avec @DataProvider. Exécutez la même méthode de test avec N entrées différentes.
• Exécution parallèle — à plusieurs granularités (suite, test, classe, méthode) configurées dans testng.xml. La fonctionnalité clé pour les suites Selenium lentes.
• Configuration XML des tests — définissez des suites de tests déclarativement en XML. Exécutez différentes combinaisons de tests sans recompiler.
• Listeners et reporters — points d'extension pour le logging personnalisé, captures d'écran en cas d'échec (Selenium) et rapports HTML personnalisés.

La classe de test TestNG canonique

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 (la comparaison honnête 2026)

L'appel pragmatique : JUnit 5 pour les tests unitaires, TestNG pour l'end-to-end et Selenium. Mélanger les deux dans un projet est bien.

TestNG et Selenium WebDriver

La raison pour laquelle TestNG reste populaire : les tests UI Selenium sont lents, instables et nécessitent une orchestration soigneuse. Fonctionnalités TestNG qui résolvent cela :

• Exécution parallèle de navigateurs. Exécutez 10 instances Chrome en parallèle contre votre suite de tests. Coupe le temps réel dramatiquement.
• Retry analyzers. Implémentez IRetryAnalyzer pour réessayer automatiquement les tests échoués N fois. Dompte l'instabilité dans Selenium.
• Listeners pour captures d'écran. Implémentez ITestListener.onTestFailure pour capturer une capture d'écran chaque fois qu'un test échoue — utile pour déboguer les instabilités UI.
• Exécutions basées sur les groupes. Exécutez les tests smoke à chaque commit, régression complète chaque nuit, le tout contrôlé via testng.xml.
• BeforeSuite setup navigateur. Ouvrez WebDriver une fois par suite (pas par test) pour amortir le coût de démarrage du navigateur.

Pièges courants de TestNG

• Dépendances inter-tests via état partagé. Les tests qui passent quand exécutés seuls mais échouent dans une suite partagent généralement des champs statiques. Chaque test devrait être indépendant.
• Race conditions d'exécution parallèle. Instances WebDriver par thread, pas par classe. Utilisez ThreadLocal<WebDriver> ou le SeleniumGrid de Selenium.
• Attentes hardcoded. Thread.sleep(5000) tue la vitesse des tests. Utilisez le WebDriverWait de Selenium avec des conditions explicites.
• Drift de testng.xml. La configuration XML devient ingérable. Gardez simple : définissez des groupes, pointez vers les packages, laissez TestNG découvrir les tests.
• Sur-utilisation de dependsOnMethods. Les longues chaînes de dépendances créent des échecs en cascade. Un échec annule 10 tests en aval, cachant le signal original.
• Pas de budget retry. Réessayer les tests instables pour toujours masque les vrais bugs. Plafonnez les retries à 2-3 et investiguez tout ce qui retry de manière constante.

Exécuter TestNG : de CLI à CI

• Maven Surefire/Failsafe — standard pour TestNG dans les projets Maven. mvn test exécute les tests unitaires ; mvn verify exécute les tests d'intégration via Failsafe.
• Gradle — useTestNG() dans la config de tests ; sinon standard.
• IntelliJ IDEA / Eclipse — support TestNG de première classe ; clic droit sur n'importe quel test → Run.
• CI (Jenkins, GitHub Actions, GitLab) — invoquez via Maven/Gradle, archivez testng-results.xml + rapports HTML personnalisés.
• Docker — pattern courant pour Selenium : Selenoid ou Selenium Grid en Docker, TestNG tourne en CI en frappant le grid.

FAQ : TestNG

Devrais-je utiliser TestNG ou JUnit 5 pour de nouveaux projets ?

Pour les tests unitaires dans des projets greenfield, JUnit 5 — c'est le par défaut dans Spring Boot et la plupart du tooling Java moderne. Pour les suites QA lourdes en Selenium, TestNG — meilleure exécution parallèle et fit d'écosystème. Beaucoup de projets utilisent les deux.

TestNG est-il toujours activement maintenu ?

Oui. TestNG a eu une ligne de release 7.x majeure (actuelle à partir de 2026) ; maintenance active et compatibilité Java 21+. Cédric Beust en est toujours le défenseur.

TestNG peut-il exécuter des tests JUnit ?

Oui. TestNG peut envelopper les tests JUnit via junit="true" dans testng.xml. Utile pendant les migrations progressives. JUnit 5 ne peut pas exécuter directement les tests TestNG.

Comment exécuter les tests TestNG en parallèle ?

Dans testng.xml : <suite parallel="methods" thread-count="4">. Granularités : suite, tests, classes, methods, instances. Methods est le plus fin mais nécessite des tests complètement indépendants.

Qu'est-ce qu'un "groupe" TestNG ?

Un tag sur une méthode de test. @Test(groups = {"smoke", "regression"}). Exécutez via testng.xml : <groups><run><include name="smoke"/></run></groups>. Vous permettant de diviser les suites de tests en smoke (rapide) et régression (lente) sans classes de test séparées.

Et pour TestNG avec Spring Boot ?

Utilisez spring-test avec TestNG via @ContextConfiguration + AbstractTestNGSpringContextTests. Spring Boot par défaut utilise JUnit 5 ; vous pouvez passer à TestNG en remplaçant les dépendances. Les docs Spring couvrent les deux.

Comment LoadFocus se rapporte à TestNG et aux tests de charge Java

TestNG couvre le testing fonctionnel Java ; pour les tests de charge des mêmes applications Java, JMeter est l'outil canonique. LoadFocus JMeter cloud testing exécute vos fichiers .jmx existants à l'échelle sur 25+ régions sans que vous ayez à gérer l'infrastructure JMeter. Utilisez TestNG pour la régression fonctionnelle, JMeter pour la validation de capacité et le monitoring d'API pour l'observabilité en production.