¿Qué es TestNG?

¿Qué es TestNG?

TestNG es un framework de testing Java de código abierto creado por Cédric Beust en 2004 para abordar carencias en JUnit 3 (que era el framework de testing Java dominante en ese momento). El nombre significa "Test Next Generation". TestNG fue diseñado no solo para tests unitarios sino para la pirámide de testing más amplia: tests de integración, tests end-to-end, tests UI con Selenium y tests de rendimiento. Aunque JUnit ha alcanzado considerablemente con JUnit 5 (Jupiter), TestNG sigue siendo la opción dominante para testing UI basado en Selenium y grandes suites de tests Java empresariales.

Si tu equipo hace QA funcional en aplicaciones Java — especialmente con Selenium WebDriver, REST Assured o herramientas similares — hay una alta probabilidad de que estés usando TestNG. La combinación TestNG + Selenium + Maven + Jenkins sigue siendo el stack canónico de QA Java en la mayoría de empresas.

Lo que TestNG ofrece que JUnit no tenía (originalmente)

Los diferenciadores originales (algunos ahora igualados por JUnit 5):

• Configuración basada en anotaciones — @Test, @BeforeMethod, @AfterClass, @DataProvider, @Listeners en lugar de subclasificar TestCase.
• Grupos de tests — etiqueta tests con @Test(groups = {"smoke", "regression"}) y ejecuta subconjuntos vía configuración XML. Fundamental para suites de tests por capas.
• Tests dependientes — @Test(dependsOnMethods = "login") declara orden de ejecución. Controvertido (los tests unitarios deberían ser independientes) pero útil para flujos end-to-end.
• Data providers — tests parametrizados con @DataProvider. Ejecuta el mismo método de test con N entradas diferentes.
• Ejecución paralela — en múltiples granularidades (suite, test, clase, método) configuradas en testng.xml. La característica clave para suites Selenium lentas.
• Configuración XML de tests — define suites de tests declarativamente en XML. Ejecuta diferentes combinaciones de tests sin recompilar.
• Listeners y reporters — puntos de extensión para logging personalizado, capturas de pantalla en fallo (Selenium) y reportes HTML personalizados.

La clase de test TestNG canónica

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 comparación honesta de 2026)

La llamada pragmática: JUnit 5 para tests unitarios, TestNG para end-to-end y Selenium. Mezclar ambos en un proyecto está bien.

TestNG y Selenium WebDriver

La razón por la que TestNG sigue siendo popular: los tests UI de Selenium son lentos, inestables y requieren orquestación cuidadosa. Características de TestNG que resuelven esto:

• Ejecución paralela de navegadores. Ejecuta 10 instancias de Chrome en paralelo contra tu suite de tests. Recorta el tiempo de reloj dramáticamente.
• Retry analyzers. Implementa IRetryAnalyzer para reintentar automáticamente tests fallidos N veces. Doma la inestabilidad en Selenium.
• Listeners para capturas de pantalla. Implementa ITestListener.onTestFailure para capturar una pantalla cada vez que un test falla — útil para depurar inestabilidades UI.
• Ejecuciones basadas en grupos. Ejecuta tests smoke en cada commit, regresión completa cada noche, todo controlado vía testng.xml.
• BeforeSuite navegador setup. Abre WebDriver una vez por suite (no por test) para amortizar el coste de arranque del navegador.

Trampas comunes de TestNG

• Dependencias entre tests vía estado compartido. Los tests que pasan cuando se ejecutan solos pero fallan en una suite normalmente comparten campos estáticos. Cada test debería ser independiente.
• Race conditions de ejecución paralela. Instancias WebDriver por hilo, no por clase. Usa ThreadLocal<WebDriver> o el SeleniumGrid de Selenium.
• Esperas hardcoded. Thread.sleep(5000) mata la velocidad del test. Usa WebDriverWait de Selenium con condiciones explícitas.
• Drift de testng.xml. La configuración XML crece inmanejable. Mantén simple: define grupos, apunta a paquetes, deja que TestNG descubra los tests.
• Sobre-uso de dependsOnMethods. Cadenas largas de dependencia crean fallos en cascada. Un fallo cancela 10 tests downstream, ocultando la señal original.
• Sin presupuesto de retry. Reintentar tests inestables para siempre enmascara bugs reales. Limita los retries a 2-3 e investiga cualquier cosa que reintenta consistentemente.

Ejecutar TestNG: de CLI a CI

• Maven Surefire/Failsafe — estándar para TestNG en proyectos Maven. mvn test ejecuta tests unitarios; mvn verify ejecuta tests de integración vía Failsafe.
• Gradle — useTestNG() en config de tests; de otra forma estándar.
• IntelliJ IDEA / Eclipse — soporte TestNG de primera clase; clic derecho en cualquier test → Run.
• CI (Jenkins, GitHub Actions, GitLab) — invoca vía Maven/Gradle, archiva testng-results.xml + reportes HTML personalizados.
• Docker — patrón común para Selenium: Selenoid o Selenium Grid en Docker, TestNG corre en CI golpeando el grid.

FAQ: TestNG

¿Debería usar TestNG o JUnit 5 para nuevos proyectos?

Para tests unitarios en proyectos greenfield, JUnit 5 — es el predeterminado en Spring Boot y en la mayoría del tooling Java moderno. Para suites QA pesadas en Selenium, TestNG — mejor ejecución paralela y encaje de ecosistema. Muchos proyectos usan ambos.

¿TestNG todavía se mantiene activamente?

Sí. TestNG tuvo una línea importante de release 7.x (actual a partir de 2026); mantenimiento activo y compatibilidad con Java 21+. Cédric Beust todavía aboga por él.

¿Puede TestNG ejecutar tests JUnit?

Sí. TestNG puede envolver tests JUnit vía junit="true" en testng.xml. Útil durante migraciones graduales. JUnit 5 no puede ejecutar tests TestNG directamente.

¿Cómo ejecuto tests TestNG en paralelo?

En testng.xml: <suite parallel="methods" thread-count="4">. Granularidades: suite, tests, classes, methods, instances. Methods es el más granular pero requiere tests completamente independientes.

¿Qué es un "grupo" de TestNG?

Una etiqueta en un método de test. @Test(groups = {"smoke", "regression"}). Ejecuta vía testng.xml: <groups><run><include name="smoke"/></run></groups>. Permitiéndote dividir suites de tests en smoke (rápida) y regresión (lenta) sin clases de test separadas.

¿Qué hay sobre TestNG con Spring Boot?

Usa spring-test con TestNG vía @ContextConfiguration + AbstractTestNGSpringContextTests. Spring Boot por defecto usa JUnit 5; puedes cambiar a TestNG reemplazando dependencias. Los docs de Spring cubren ambos.

Cómo se relaciona LoadFocus con TestNG y pruebas de carga Java

TestNG cubre el testing funcional Java; para pruebas de carga de las mismas aplicaciones Java, JMeter es la herramienta canónica. LoadFocus JMeter cloud testing ejecuta tus archivos .jmx existentes a escala en 25+ regiones sin que tengas que gestionar la infraestructura JMeter. Usa TestNG para regresión funcional, JMeter para validación de capacidad y monitorización de API para observabilidad en producción.