Qu'est-ce que TestNG ?

TestNG est un framework de tests Java : annotations, groupes, data providers, exécution parallèle. Fonctionnement et comparaison avec JUnit 5.

Qu'est-ce que TestNG ?

TestNG est un framework de tests Java open source, inspiré de JUnit et NUnit. On marque les tests et le code d'initialisation avec des annotations, et il ajoute des groupes, des data providers, des dépendances entre tests et l'exécution parallèle. Il couvre les tests unitaires, fonctionnels, de bout en bout et d'intégration, ce qui explique sa présence dans de nombreuses suites d'interface avec Selenium. Le nom signifie Test Next Generation.

Comment fonctionne TestNG

Un test est une méthode annotée avec @Test dans une classe Java classique. L'initialisation et le nettoyage passent par des annotations de configuration qui s'exécutent à différents niveaux : @BeforeSuite, @BeforeTest, @BeforeClass et @BeforeMethod, chacune avec son pendant @After.... On lance les tests depuis l'IDE, depuis Maven ou Gradle, ou via un fichier testng.xml qui indique les classes, paquets ou groupes à inclure.

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 addsTwoNumbers() {
        assertEquals(calc.add(2, 3), 5);
    }

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

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

Chaque @BeforeMethod s'exécute avant chaque test, et le data provider envoie trois jeux de données à divides : le rapport affiche donc trois résultats pour une seule méthode.

Principales fonctions de TestNG

  • Groupes : marquez un test avec @Test(groups = {"smoke"}) et choisissez les groupes dans testng.xml, par exemple les tests de fumée à chaque commit et l'ensemble chaque nuit.
  • Dépendances : dependsOnMethods exécute un test après les méthodes citées. Si l'une échoue, le test dépendant est marqué SKIP et non FAIL, sauf si vous ajoutez alwaysRun=true.
  • Data providers : @DataProvider exécute une méthode de test avec de nombreuses entrées. Avec parallel = true sur le provider, ces appels s'exécutent en parallèle. Un exemple complet est disponible dans comment utiliser le DataProvider dans TestNG.
  • Analyseurs de nouvelle tentative : implémentez IRetryAnalyzer et liez-le avec @Test(retryAnalyzer = ...) pour relancer les tests échoués.
  • Listeners : ils réagissent au début, au succès et à l'échec d'un test, par exemple pour enregistrer une capture d'écran quand un test d'interface échoue.
  • Compatibilité JUnit : TestNG sait exécuter des tests JUnit 3 et JUnit 4, ce qui aide lors d'une migration progressive.

Exécuter les tests TestNG en parallèle

Le parallélisme se règle sur la suite, dans testng.xml. L'attribut parallel choisit l'unité qui reçoit son propre thread et thread-count fixe le nombre de threads disponibles :

  • methods : chaque méthode de test s'exécute dans son propre thread.
  • tests : chaque bloc <test> reçoit un thread que ses méthodes partagent.
  • classes : chaque classe reçoit un thread.
  • instances : les méthodes d'une même instance partagent un thread ; des instances différentes peuvent tourner en même temps.
<suite name="Regression" parallel="methods" thread-count="4">
  <test name="Smoke">
    <groups><run><include name="smoke"/></run></groups>
    <packages><package name="com.example.tests"/></packages>
  </test>
</suite>

Les data providers parallèles utilisent leur propre pool, réglé avec data-provider-thread-count (10 par défaut). L'exécution parallèle n'aide que si les tests sont indépendants. Avec Selenium, gardez un WebDriver par thread, par exemple dans un ThreadLocal.

TestNG ou JUnit 5

Les deux sont matures et fonctionnent avec Maven, Gradle, Selenium et REST Assured. Les différences pratiques tiennent à ce qui est intégré :

  • Suites et groupes : TestNG fournit testng.xml et groups. JUnit 5 utilise @Tag et les filtres de l'outil de build.
  • Dépendances entre tests : TestNG les gère. JUnit 5 ne les prévoit pas, par choix, ce qui pousse vers des tests indépendants.
  • Tests paramétrés : @DataProvider dans TestNG, @ParameterizedTest dans JUnit 5.
  • Exécution parallèle : intégrée à la configuration de suite de TestNG. JUnit 5 peut aussi s'exécuter en parallèle, après activation par configuration.

Pour de nouveaux tests unitaires, les deux conviennent : suivez l'outillage déjà en place dans votre équipe. Les mélanger dans un projet est possible, mais source de confusion.

Erreurs fréquentes avec TestNG

  • État partagé entre les tests. Un test qui réussit seul et échoue dans la suite dépend souvent d'un champ statique modifié par un autre test.
  • Un seul WebDriver pour tous les threads. Cela marche en série et casse le jour où vous activez parallel.
  • De longues chaînes de dependsOnMethods. Un échec fait sauter tout ce qui suit et masque la cause initiale.
  • Des attentes fixes. Thread.sleep(5000) ralentit la suite sans supprimer l'instabilité. Attendez plutôt une condition explicite.
  • Des relances illimitées. Relancer un test instable jusqu'à ce qu'il passe cache de vrais bugs. Limitez à une ou deux relances et examinez tout test qui en a besoin.
  • Un testng.xml qui liste chaque test à la main. Pointez vers des paquets et des groupes et laissez TestNG découvrir les classes.

TestNG, tests de régression et performance

TestNG répond à la question « est-ce que cela se comporte toujours correctement ? », c'est le rôle des tests de régression. Il ne dit pas comment le système tient avec de nombreux utilisateurs simultanés. Il faut pour cela des tests de charge, et pour les systèmes Java l'outil habituel est JMeter. LoadFocus exécute vos scripts JMeter existants sans modification depuis 25 régions cloud, et la surveillance d'API vérifie les codes de statut, les corps de réponse et la latence selon un calendrier une fois le code en production. Les tests TestNG, les tests de charge et la surveillance couvrent des défaillances différentes : aucun ne remplace les autres.

Questions fréquentes : TestNG

Faut-il choisir TestNG ou JUnit 5 pour un nouveau projet ?

Les deux sont de bons choix. TestNG fournit d'emblée fichiers de suite, groupes, dépendances et réglages de parallélisme, ce qui convient aux grandes suites Selenium. JUnit 5 convient bien aux tests unitaires simples. Prenez celui que votre équipe et votre build utilisent déjà.

TestNG est-il toujours maintenu ?

Oui, TestNG 7.x continue de recevoir des versions. À partir de la 7.6.0, il faut JDK 11 ou plus récent ; la 7.5 et les précédentes fonctionnent avec JDK 8. Consultez le site de TestNG ou Maven Central pour la version actuelle.

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

Définissez parallel et thread-count sur la suite dans testng.xml, par exemple <suite parallel="methods" thread-count="4">. Les valeurs possibles sont methods, tests, classes et instances. Vérifiez d'abord que les tests ne partagent pas d'état modifiable.

TestNG peut-il exécuter des tests JUnit ?

Il peut exécuter des tests JUnit 3 et JUnit 4 si le test est marqué junit="true" dans testng.xml. Les tests JUnit 5 (Jupiter) passent en revanche par la JUnit Platform.

Pourquoi mon test TestNG est-il ignoré au lieu d'échouer ?

Un test qui utilise dependsOnMethods est ignoré lorsqu'une méthode dont il dépend échoue. Corrigez d'abord la dépendance en échec, ou ajoutez alwaysRun=true si le test doit s'exécuter dans tous les cas.

Quelle est la vitesse de votre site web?

Augmentez sa vitesse et son référencement naturel de manière transparente avec notre Test de Vitesse gratuit.

Test gratuit de vitesse du site Web

Analyser la vitesse de chargement de votre site Web et améliorer ses performances avec notre outil gratuit de vérification de la vitesse de la page.