TestNG Oyentes en Selenium
Krishna rungta
⚡ Resumen inteligente
Oyentes en Selenium WebDriver son TestNG Interfaces que interceptan eventos de prueba para personalizar registros, informes y acciones posteriores a fallos. Este artículo explica los métodos de ITestListener y muestra un ejemplo ejecutable. Java ejemplo, y aclara cómo Selenium La versión 4 reemplazó al WebDriverEventListener obsoleto.
Selenium Los scripts de WebDriver a menudo necesitan reaccionar a eventos de prueba como una aserción pasada, un localizador fallido o un paso omitido. Los oyentes hacen eso posible. En términos generales, Selenium Los proyectos dependen de dos familias de oyentes:
- Oyentes de WebDriver
- TestNG Oyentes
En este tutorial, nos centraremos en TestNG Oyentes, con una nota sobre cómo cambiaron los oyentes a nivel de WebDriver en Selenium 4.x.
¿Qué es un oyente en TestNG?
Un Listener es una interfaz que modifica el comportamiento predeterminado de TestNG. Como su nombre lo indica, los Listeners “escuchan” eventos definidos en un Selenium Escriba el script y reaccione en consecuencia. Los utiliza implementando la interfaz Listener correspondiente y registrándola en su clase o conjunto de pruebas. Los Listeners le permiten personalizar TestNG Informes, adjuntar capturas de pantalla y generar registros estructurados.
Tipos de oyentes en TestNG
TestNG La compañía distribuye una familia de interfaces de escucha, y cada una está dirigida a una etapa diferente del ciclo de vida de las pruebas.
A continuación se muestran los más utilizados TestNG oyentes:
- IAnotaciónTransformador
- IAnotaciónTransformer2
- Configurable
- IConfigurationListenerIConfigurationListener
- IExecutionListener
- Enganchable
- IInvokedMethodListener
- IInvokedMethodListener2
- IMétodoInterceptor
- Reportero
- ISuiteListener
- ITestListener
Estas interfaces se utilizan en Selenium para generar registros o personalizar TestNG informes. En este tutorial, implementaremos ITestListener.
ITestListener expone los siguientes métodos:
- al inicio – Se llama cuando comienza cualquier prueba.
- onTestSuccess – Se llama cuando una prueba se supera.
- en caso de fallo de la prueba – Se llama cuando falla una prueba.
- en prueba omitida – Se llama cuando se omite una prueba.
- en prueba fallida pero dentro del porcentaje de éxito – Se llama así cuando una prueba falla, pero está dentro del porcentaje de éxito.
- onFinish – Se llama después de que se hayan ejecutado todas las pruebas de la clase.
Escenario de prueba
En este escenario de prueba, automatizaremos el proceso de inicio de sesión e implementaremos ITestListener En contra.
- Lanza Firefox y abre el sitio https://demo.guru99.com/V4/
- Inicia sesión en la aplicación.
Pasos para crear un TestNG Perfil
Para el escenario de prueba anterior, implementaremos el Listener paso a paso.
Paso 1) Crea una clase llamada Prueba de oyente que implementa ITestListener. Pase el cursor sobre la línea roja subrayada y Eclipse Sugeriremos dos soluciones rápidas, como se muestra a continuación:
Haz clic en “Agregar métodos no implementados”. Se agregarán varios métodos stub (sin cuerpo) a tu código, de forma similar a esto:
importar org.testng.ITestContext;
importar org.testng.ITestListener;
importar org.testng.ITestResult;
clase pública Prueba de oyente implementos ITestListener {
@Anular
vacío público onFinish(Contexto de prueba de TI arg0) {
// TODO Método generado automáticamente
}
@Anular
vacío público al inicio (Contexto de prueba de TI arg0) {
// TODO Método generado automáticamente
}
@Anular
vacío público en prueba fallida pero dentro del porcentaje de éxito (Resultado de la prueba de TI arg0) {
// TODO Método generado automáticamente
}
@Anular
vacío público onTestFailure(Resultado de la prueba de TI arg0) {
// TODO Método generado automáticamente
}
@Anular
vacío público onTestSkipped(Resultado de la prueba de TI arg0) {
// TODO Método generado automáticamente
}
@Anular
vacío público al inicio de la prueba (Resultado de la prueba de TI arg0) {
// TODO Método generado automáticamente
}
@Anular
vacío público onTestSuccess(Resultado de la prueba de TI arg0) {
// TODO Método generado automáticamente
}
}
Ahora modifiquemos el Prueba de oyente clase. En particular, completaremos los siguientes métodos: en caso de fallo de la prueba, enPruebaOmitida, al inicio de la prueba, y en caso de éxito de la prueba.
El cambio es sencillo: cada método imprime el nombre de la prueba para que la consola muestre claramente el estado de aprobado, reprobado y omitido.
Tras la modificación, el código queda así:
importar org.testng.ITestContext;
importar org.testng.ITestListener;
importar org.testng.ITestResult;
clase pública Prueba de oyente implementos ITestListener {
@Anular
vacío público onFinish(Contexto de prueba de TI Resultado) {
}
@Anular
vacío público al inicio (Contexto de prueba de TI Resultado) {
}
@Anular
vacío público en prueba fallida pero dentro del porcentaje de éxito (Resultado de la prueba de TI Resultado) {
}
// Cuando falla un caso de prueba, se llama a este método.
@Anular
vacío público onTestFailure(Resultado de la prueba de TI Resultado) {
System.out.println (“El nombre del caso de prueba que falló es: “ + Resultado.getName());
}
// Cuando se omite un caso de prueba, se llama a este método.
@Anular
vacío público onTestSkipped(Resultado de la prueba de TI Resultado) {
System.out.println (“El nombre del caso de prueba omitido es: “ + Resultado.getName());
}
// Este método se llama cuando se inicia un caso de prueba.
@Anular
vacío público al inicio de la prueba (Resultado de la prueba de TI Resultado) {
System.out.println(Result.getName() + “Caso de prueba iniciado”);
}
// Cuando una prueba se supera, se llama a este método.
@Anular
vacío público onTestSuccess(Resultado de la prueba de TI Resultado) {
System.out.println (“El nombre del caso de prueba superado es: “ + Resultado.getName());
}
}
Paso 2) Crea otra clase llamada Casos de prueba para la automatización del inicio de sesión. Selenium Esta clase se ejecutará para iniciar sesión en el sitio de demostración.
importar org.openqa.selenium.By;
importar org.openqa.selenium.WebDriver;
importar org.openqa.selenium.firefox.FirefoxConductor;
importar org.testng.Assert;
importar org.testng.annotations.Listeners;
importar org.testng.anotaciones.Prueba;
clase pública Casos de prueba {
Controlador web conductor = ¡nuevos Socios! de FirefoxDestornillador();
// Prueba diseñada para pasar, para verificar el oyente de éxito.
@Prueba
vacío público Acceso() {
conductor.obtener(“https://demo.guru99.com/V4/”);
conductor.findElement(Por.nombre(“uid”)).sendKeys(“mngr34926”);
conductor.findElement(Por.nombre("contraseña")).sendKeys(“amUpenu”);
conductor.findElement(Por.nombre(“btnLogin”)).hacer clic();
}
// Prueba fallida forzadamente, para verificar el detector de fallos.
@Prueba
vacío público TestToFail() {
System.out.println (“Este método de prueba falla”);
Afirmar.afirmarVerdadero(false);
}
}
Paso 3) A continuación, adjuntamos este oyente a nuestra clase de prueba. Casos de pruebaHay dos maneras de conectar una clase a una interfaz de escucha.
La primera forma es utilizar el @Oyentes anotación, como se muestra a continuación:
Agregamos esta anotación encima de la Casos de prueba clase. La clase quedaría así:
importar org.openqa.selenium.By;
importar org.openqa.selenium.WebDriver;
importar org.openqa.selenium.firefox.FirefoxConductor;
importar org.testng.Assert;
importar org.testng.annotations.Listeners;
importar org.testng.anotaciones.Prueba;
@Listeners(Listener_Demo.ListenerTest.class)
clase pública Casos de prueba {
Controlador web conductor = ¡nuevos Socios! de FirefoxDestornillador();
// Prueba para pasar, para verificar el oyente de éxito.
@Prueba
vacío público Acceso() {
conductor.obtener(“https://demo.guru99.com/V4/”);
conductor.findElement(Por.nombre(“uid”)).sendKeys(“mngr34926”);
conductor.findElement(Por.nombre("contraseña")).sendKeys(“amUpenu”);
conductor.findElement(Por.nombre(“btnLogin”)).hacer clic();
}
// Prueba fallida forzadamente, para verificar el detector de fallos.
@Prueba
vacío público TestToFail() {
System.out.println (“Este método de prueba falla”);
Afirmar.afirmarVerdadero(false);
}
}
La estructura del proyecto es la siguiente:
Paso 4) Ejecute el Casos de prueba Clase. Métodos dentro Prueba de oyente se invocan automáticamente en función del comportamiento de los métodos anotados con @Prueba.
Paso 5) Verifique la salida que se muestra en la consola.
La salida de Casos de prueba parece:
C:\Users\gauravn\AppData\Local\Temp\testng-eclipse–1058076918\testng-customsuite.xml
Se ha iniciado el caso de prueba de inicio de sesión.
El nombre del caso de prueba superado es: Login
Se ha iniciado el caso de prueba TestToFail.
Este método para probar falla
El nombre del caso de prueba que falló es: TestToFail
APROBADO: Iniciar sesión
FALLÓ: TestToFail
java.lang.AssertionError: se esperaba [true] pero se encontró [false]
Uso de un oyente para múltiples clases
Si un proyecto tiene muchas clases de prueba, agregar la @Oyentes La anotación de cada uno se vuelve engorrosa y propensa a errores.
En ese caso, crea un pruebang.xml archiva y registra el oyente allí una sola vez.
Este detector de eventos se aplica a todo el conjunto de pruebas, independientemente del número de clases. Al ejecutar el archivo XML, el detector se activa para cada clase declarada en el conjunto, y se pueden encadenar varias clases detectoras dentro de la misma etiqueta.
WebDriverListener en Selenium 4 frente al obsoleto EventFiringWebDriver
Aunque TestNG Los oyentes reaccionan a los eventos del ciclo de vida de la prueba, los oyentes de WebDriver reaccionan a las acciones del controlador del navegador, como un clic, una navegación o una llamada findElement. En Selenium 3 El enfoque típico fue el Oyente de eventos de WebDriver interfaz cableada a través de EventFiringWebDriverAmbos están obsoletos en Selenium 4.x.
El reemplazo moderno es el WebDriverListener Interfaz combinada con Decorador de eventos:
importar org.openqa.selenium.chrome.ChromeDriver;
importar org.openqa.selenium.support.events.EventFiringDecorator;
importar org.openqa.selenium.support.events.WebDriverListener;
clase pública LoggingListener implementos WebDriverListener {
@Anular
vacío público antes de obtener (Controlador web conductor, String url) {
System.out.println (“Navegando hacia “ + url);
}
}
Controlador web crudo = ¡nuevos Socios! de ChromeDriver();
Controlador web conductor = ¡nuevos Socios! de Decorador de eventos<>(¡nuevos Socios! de LoggingListener()).decorate(raw);
El decorador puede envolver cualquier WebDriver, WebElement o Alert, lo que es más flexible que el antiguo envoltorio de disparo de eventos. WebDriverListener para la observabilidad del lado del navegador y TestNG ITestListener para la generación de informes a nivel de suite.
Oyentes impulsados por IA: Registros más inteligentes y clasificación de fallos.
MODERNA Selenium Los equipos integran cada vez más servicios de IA en sus oyentes para que las señales de CI sean más procesables. en caso de fallo de la prueba, un oyente asistido por IA puede capturar una instantánea del DOM más una captura de pantalla, enviarlas a un modelo que devuelve un clúster de causa raíz probable y escribir una etiqueta de vuelta en el TestNG informe o una herramienta como ReportPortal.
Los patrones comunes impulsados por la IA incluyen:
- Detección de pruebas defectuosas: Los oyentes envían cronogramas de aprobación/rechazo a un modelo que clasifica un fallo como inestable, ambiental o una regresión real.
- Capturas de pantalla inteligentes: Los modelos de visión artificial recortan, anotan y comparan las capturas de pantalla de la interfaz de usuario para que los revisores vean la región modificada en lugar de una página completa.
- Localizadores autorreparables: A WebDriverListener manos antesDeBuscarElemento y le pide a un asistente de IA que sugiera un localizador alternativo cuando el principal falle. Ninguna excepción de elemento tal.
- Resúmenes en lenguaje natural: An Reportero La implementación introduce los resultados del conjunto en un LLM que produce un resumen de un párrafo.
La capa de escucha es el lugar más limpio para inyectar estos ganchos porque se mantiene fuera de la lógica de la prueba y se aplica de manera uniforme en toda la suite.
Resumen
Los oyentes deben generar registros o personalizarlos TestNG informes en Selenium Controlador web.
- TestNG Ofrece numerosas interfaces de escucha; elige la que mejor se adapte al evento que te interesa.
- Los oyentes son interfaces utilizadas en Selenium Scripts de WebDriver para reaccionar a los eventos del ciclo de vida de las pruebas.
- El tutorial demostró ITestListener con una prueba de aprobado y otra de suspenso.
- Puedes adjuntar un oyente con @Oyentes o registrarlo una vez en pruebang.xml para toda la suite.
- Selenium 4.x reemplaza EventFiringWebDriver con WebDriverListener + Decorador de eventos para eventos a nivel de WebDriver.
