Menú

Anotaciones y oyentes de TestNG

testng annotations listeners

Pruebe Nuestro Instrumento Para Eliminar Los Problemas

Este tutorial explica los diferentes tipos de anotaciones y oyentes de TestNG. También aprenderá a usar las anotaciones y escuchas de TestNG con ejemplos:

Aquí, ejecutaremos un programa TestNG básico usando anotaciones de TestNG y también veremos el rol de los oyentes de TestNG y cómo usarlos en las pruebas.

=> Lea la serie de formación Easy TestNG.

Anotaciones y oyentes de TestNG

Lo que vas a aprender:

¿Qué son las anotaciones de TestNG?

Estos son el programa o la lógica empresarial que se utilizan para controlar el flujo de métodos. Juegan un papel muy importante en TestNG. Estas anotaciones difieren en cada proyecto según los requisitos. El flujo de anotaciones sigue siendo el mismo en todos los programas a pesar de los diferentes requisitos.

Hay diferentes tipos de anotaciones de TestNG que hacen que TestNG sea más fácil y mejor que JUnit. Cada una de estas anotaciones se ejecutará en un evento específico en TestNG.

Tipos de anotaciones en TestNG

A continuación se muestran las listas de anotaciones y sus atributos que se utilizan en TestNG. Vamos a explorarlos y sus usos en detalle.

Antes

  • @BeforeSuite: Este método se ejecutará antes de que se ejecuten todas las pruebas de la suite.
  • @BeforeTest: Este método se ejecutará antes de que se declare cada sección de prueba en la suite.
  • @Antes de clase: Este método se ejecutará antes que el primer método de prueba en la clase actual.
  • @BeforeMethod: Este método se ejecutará antes de cada método de prueba.
  • @BeforeGroups: Este método se ejecutará antes de que se mencione cualquier método de prueba del grupo especificado.
  • @Prueba : Marca una clase o un método como parte de la prueba. O podemos decir que hace un método como método de prueba.

Después

  • @AfterSuite: Este método se ejecutará después de que se ejecuten todas las pruebas de la suite.
  • @Después de la prueba: Este método se ejecutará después de que se declare cada sección de prueba en la suite.
  • @Después de clases: Este método se ejecutará después del último método de prueba de la clase.
  • @AfterMethod: Este método se ejecutará después de que se ejecute cada método de prueba.
  • @AfterGroups: Este método se ejecutará después de que se ejecute el último método de prueba del grupo especificado.

Flujo de trabajo de anotaciones

Cuando ejecutamos el archivo TestNG.xml, las anotaciones de TestNG se ejecutarán en la siguiente secuencia:

Before Suite-> Before Test-> Before Class-> Before Method-> @Test -> After Method-> After Class-> After Test-> After Suite

|_+_|

@Prueba tiene muchos otros atributos que nos ayudan a ejecutar nuestros casos de prueba de manera más efectiva.

A continuación se muestran los tipos de atributos y sus descripciones con ejemplos.

# 1) alwaysRun: Cuando se establece en verdadero, este método se ejecutará incluso si depende de un método que haya fallado.

Ejemplo: Prueba (alwaysRun = true)

# 2) proveedor de datos : Muestra el nombre del proveedor de datos para este método. Solo tiene atributos, es decir, nombre. Podemos usarlo cuando probamos nuestro software con múltiples conjuntos de datos en el momento de la entrada o en el tiempo de ejecución. Esto también se conoce como prueba basada en datos. Podemos hacer pruebas basadas en datos utilizando este atributo.

Ejemplo: @dataProvider (nombre = 'TestData')

# 3) dataProviderClass : Este atributo le permitirá especificar la clase de proveedor de datos que contendrá el proveedor de datos que utilizará el método @Test.

Ejemplo: @Test (dataProvider = 'Prueba de datos del cliente', dataProviderClass = ClientDetailsTest.class)

#4) dependsOnGroups : Este atributo depende de la lista de grupos, es decir, el método de prueba comenzará la ejecución solo después de que se ejecuten los grupos dependientes.

Nota : Si falla alguna de las pruebas de los grupos que dependen de él, se omitirá esa prueba.

A continuación se muestra el ejemplo:

|_+_|

#5) dependsOnMethods : Esta anotación depende de la lista de métodos. Esto significa que el método de prueba comenzará a ejecutarse solo después de que se ejecuten los métodos dependientes.

Nota : Si falla alguna de las pruebas en los métodos que son dependientes, se omitirá esa prueba.

Ejemplo:

|_+_|

# 6) alwaysRun = true: Podemos establecer los atributos en un método de prueba en verdadero, y esto forzará la ejecución de la prueba incluso si algunas de las pruebas en el grupo dependen de fallar.

Por ejemplo:

|_+_|

# 7) descripción : Proporciona la descripción del método. Generalmente, contiene un resumen de una línea.

Ejemplo:

|_+_|

# 8) habilitado : Este atributo ayuda a especificar si queremos ejecutar el método de prueba en particular en la suite / clase actual o no. A veces, no queremos ejecutar algunas pruebas debido a algunas razones, como que el requisito / función cambia con frecuencia y no queremos alterar la ejecución actual de esa función en particular.

En esos casos, podemos simplemente ignorar / deshabilitar esa prueba en particular configurando esta función como @Test (habilitado = falso).

Ejemplo:

|_+_|

# 9) excepciones esperadas : Este atributo muestra la lista de excepciones que el método de prueba arrojará en el tiempo de ejecución. Si no se lanza ninguna excepción o cualquier otra excepción para el método, la prueba se marca como un error.

Ejemplo:

|_+_|

# 10) grupos : Este atributo se utiliza para especificar los grupos a los que pertenece el método de prueba.

|_+_|

# 11) prioridad : Esto ayuda a priorizar los métodos de prueba, mientras que la prioridad predeterminada comienza con 0 y las pruebas se ejecutan en orden ascendente.

Ejemplo:

|_+_|

Resultados: A continuación se muestran los resultados según la prioridad, aunque no se asignó ningún número a la primera prueba, tomó su prioridad por defecto como 0 y la ejecución se realizó en orden ascendente.

Aprobado: launchApp
Aprobado: loginApp
Aprobado: checkTrans

# 12) tiempo de espera : Este atributo ayuda a especificar un valor de tiempo de espera para la prueba (generalmente se usa como milisegundos). Si la prueba tarda más del valor de tiempo de espera especificado, la prueba se marca como fallida. Podemos usar este tiempo de espera para realizar una prueba de rendimiento, para asegurarnos de que el método está regresando dentro de un tiempo razonable.

|_+_|

# 13) invocationCount : Este atributo ayuda a determinar el número de veces que se debe invocar un método de prueba.

|_+_|

Producción:

El título de la página es Google
El título de la página es Google
El título de la página es Google
El título de la página es Google
El título de la página es Google

#14) invocationTimeOut: Este es el tiempo máximo (número de milisegundos) que esta prueba debe tomar para todos los recuentos de invocaciones. Este método debe usarse junto con el método de recuento de invocaciones o, de lo contrario, se ignoraría.

Ejemplo:

|_+_|

El ejemplo anterior muestra que esta prueba tardará un total de 4 segundos en ejecutarse y cada vez que se invoca / ejecuta la prueba, tardaría 1 segundo en ejecutarse.

# 15) @DataProvider : Este método ayuda a proporcionar datos para un método de prueba. Primero, tenemos que declarar un método anotado por @DataProvider y luego usar este método en el método de prueba requerido usando el atributo 'DataProvider' en la anotación @Test.

Un proveedor de datos devuelve una matriz de objetos, especialmente una matriz de objetos bidimensionales () (). La primera matriz representa un conjunto de datos y la segunda matriz contiene los parámetros.

@DataProvider (name = 'Test'): aquí, el nombre representa el nombre del proveedor de datos. Si no se proporciona el nombre, el nombre del proveedor de datos se establecerá automáticamente como el nombre del método.

Ejemplo:

|_+_|

# 16) @Fábrica : Esto se usa para especificar un método como una fábrica para proporcionar objetos que serán usados ​​por TestNG para sus clases de prueba. Al usar @Factory, podemos crear pruebas dinámicas en tiempo de ejecución y debería devolver un objeto de matriz.

Ejemplo:

Tomemos un ejemplo para entenderlo mejor. Crearemos dos clases, es decir, FactorySample.Java y FactoryTest.Java

FactorySample.Java

|_+_|

FactoryTest.Java

|_+_|

Producción : Google se lanzó con éxito

Gmail ha iniciado sesión correctamente

Diferencia entre las anotaciones @Factory y @DataProvider

Existe una diferencia básica entre ambas anotaciones. Hay mucha confusión con respecto a estas dos anotaciones, como dónde usarlas y por qué.

Busquemos las respuestas.

@Proveedor de datos: Esta anotación parametrizará el método de prueba particular y ejecutará la prueba en un no específico. de veces en función de los datos proporcionados por este método.

Por ejemplo, si hay dos parámetros, el método de prueba se ejecutará dos veces. Por ejemplo, si queremos iniciar sesión en un sitio con diferentes conjuntos de nombres de usuario y contraseñas cada vez, esto es útil ya que tenemos que proporcionar los parámetros para probar.

@Fábrica : Esto ejecutará todos los métodos de prueba presentes dentro del archivo de clase de prueba mientras se usa una instancia separada de esa clase. Esto es útil si queremos ejecutar la clase de prueba cualquier número de veces.

Por ejemplo , si tenemos que probar la función de inicio de sesión de cualquier aplicación o sitio web y como tenemos que ejecutar esta prueba varias veces, es mejor usar @Factory donde podemos crear múltiples instancias de prueba y ejecutar las pruebas.

Echemos un vistazo a estos ejemplos para conocer la diferencia.

@DataProvider Ejemplo :

|_+_|

Nota : En el programa anterior hemos proporcionado dos datos y el resultado del programa sería:

Los nombres son: Mihir 145632
Los nombres son: Kumar 28242

Esto muestra que si aumentamos el número de datos en el método de mensaje, entonces el método de impresión se ejecutará el mismo número de veces.

@Factory Ejemplo :

TestNG Factory es muy útil cuando tenemos que ejecutar múltiples clases de prueba usando una sola clase de prueba.

Veamos un ejemplo.

Para ello, tenemos que crear dos clases de prueba con pocos métodos de prueba dentro de ellas.

TestData 1:

|_+_|

TestData 2:

|_+_|

Ahora tenemos que definir el método @Factory que devuelve una matriz de objetos de las clases definidas anteriormente.

Programa de fábrica:

|_+_|

Producción:

Método de prueba Test1
Método de prueba Test2
APROBADO: test1
APROBADO: test2

Oyentes de TestNG con tipos

En términos simples, los oyentes escuchan el evento definido en el script de Selenium y se comportan de acuerdo con él. El objetivo principal es crear registros y personalizar los informes de TestNG.

Hay muchos tipos de oyentes disponibles en TestNG.

Por ejemplo , IAnnotationTransformer, IAnnotationTransformer2, IConfigurable, IConfigurationListener, IConfigurationListener2, IExecutionListener, IHookable, IInvokedMethodListener, IInvokedMethodListener2, IMethodInterceptor, IReporter, ISuiteListener

Sin embargo, cuando se trata de pruebas, solo usamos algunas de ellas, como se explica a continuación:

# 1) ISuiteListener

Este es un oyente para suites de prueba. Consiste en dos métodos, es decir onStart () y onFinish () .

Siempre que implementemos este oyente, garantizará que el usuario final invocará los métodos onStart () y onFinish () antes y después de ejecutar una suite TestNG.

Detalles del método:

void onStart (suite ISuite) : Este método se invoca antes de que se inicie Suite Runner.

void onFinish (suite ISuite) : Este método se invoca después de que Suite Runner haya ejecutado todas las suites de prueba.

Ejemplo:

|_+_|

# 2) ITestListener

Este oyente funciona igual que ISuiteListener. Sin embargo, la única diferencia es que realiza la llamada antes y después de la Prueba y no la Suite. Es un oyente para la ejecución de pruebas y este oyente tiene siete métodos.

(i) onStart () :Este método se invoca después de crear una instancia de la clase de prueba y antes de llamar a cualquier método de configuración.

Ejemplo:

|_+_|

(ii) enFinish () :Este método se invoca después de que se hayan ejecutado todas las pruebas y se hayan llamado a todos los métodos de configuración.

Ejemplo:

|_+_|

(iii) onTestStart () :Este método se invoca cada vez que se invoca una prueba. El ITestResult solo se llena parcialmente con las referencias a clase, método, milisegundos de inicio y estado.

Método: void onTestStart (resultado de ITestResult)

Ejemplo:

|_+_|

(iv) onTestSuccess () :Este método se invoca cada vez que una prueba tiene éxito.

Método: void onTestSuccess (resultado de ITestResult)

Ejemplo:

|_+_|

(v) onTestFailure () :Este método se invoca cada vez que falla una prueba.

Método: void onTestFailure (resultado de ITestResult)

Ejemplo:

|_+_|

(vi) onTestSkipped () :Este método se invoca cada vez que se omite una prueba.

Método: void onTestSkipped (resultado de ITestResult)

Ejemplo:

|_+_|

(vii) onTestFailedButWithinSuccessPercentage :Este método se invoca cada vez que un método falla, pero se ha anotado con el porcentaje de éxito y el error lo mantiene dentro del porcentaje de éxito.

Método: void onTestFailedButWithinSuccessPercentage (resultado de ITestResult)

Ejemplo:

|_+_|

# 3) IExecutionListener

Es un oyente que monitorea el comienzo y el final de una ejecución de TestNG. Tiene dos métodos, es decir onExecutionStart () y onExecutionFinish () .

Se llama al método onExecutionStart () antes de que TestNG comience a ejecutar las suites y se llama al método onExecutionFinish () después de que TestNG termina con la ejecución de todas las suites de prueba.

Método:

void onExecutionStart ()

void onExecutionFinish ()

Ejemplo:

|_+_|

# 4) IInvokedMethodListener

Es un oyente que se invoca antes y después de que TestNG invoca un método. Este oyente se invoca solo para configuraciones y métodos de prueba. Tiene solo dos métodos, es decir, afterInvocation y beforeInvocation.

  1. antes de la invocación: Invocar antes de cada método.
  2. afterInvocation: Invocar después de cada método.

Método:

void beforeInvocation (método IInvokedMethod, ITestResult testResult)

void afterInvocation (método IInvokedMethod, ITestResult testResult)

Ejemplo:

|_+_|

# 5) Interceptor de método

Esta clase se utiliza para modificar la lista de métodos de prueba que va a ejecutar TestNG. Al utilizar este método, podemos reordenar la lista de métodos de prueba.

Es aplicable solo a aquellos métodos que no tienen dependientes y aquellos métodos que no dependen de ningún otro método de prueba se pasarán en los parámetros. Esta interfaz devolverá una lista de métodos de prueba que deben ejecutarse, pero de una manera diferente.

Método:

Salesforce prueba entrevistas preguntas y respuestas pdf

intercepción java.util.List (métodos java.util.List, contexto ITestContext)

Ejemplo:

|_+_|

# 6) Reportero

Esto es implementado por los clientes para generar un informe. Este método se invocará una vez que se haya ejecutado toda la suite y los parámetros proporcionen todos los resultados de las pruebas que ocurrieron durante esa ejecución.

Método:

Void generateReport (java.util.List xmlSuites, java.util.List suites, java.lang.String outputDirectory)

Ejemplo:

|_+_|

Conclusión

En este artículo, hemos visto cómo las anotaciones de TestNG pueden ser útiles para facilitar la lógica de nuestro programa. Las anotaciones se utilizan según sea necesario.

Puede pasar los parámetros a las anotaciones y realizar pruebas basadas en datos también. Puede ejecutar los casos de prueba en grupos y ahorrar tiempo. Con los oyentes, incluso puede generar los informes. ¿No crees que esto es maravilloso?

TestNG.xml se explicará en detalle en nuestro próximo tutorial. Este archivo XML es la columna vertebral del marco TestNG y nos ayudará a ejecutar nuestros casos de prueba.

=> Consulte la guía de capacitación perfecta de TestNG aquí.

Lectura recomendada

^