En este post, aprenderemos a reproducir casos de prueba fallidos utilizando TestNG. Exploraremos dos enfoques para conseguirlo, a saber: utilizando el archivo testng-failed.xml e implementando el IRetryAnalyzer de testNG.<\/p>\n\n
A veces, como probadores de automatizaci\u00f3n de pruebas, s\u00f3lo se nos pide que ejecutemos pruebas fallidas informadas por la herramienta de automatizaci\u00f3n de pruebas despu\u00e9s de corregir algunos errores. Ejecutar s\u00f3lo las pruebas fallidas verificar\u00e1 r\u00e1pidamente las correcciones de errores.<\/p>\n\n
Ejecutar s\u00f3lo las pruebas fallidas es relativamente f\u00e1cil, ya que TestNG proporciona un soporte natural para ello. Siempre que se ejecute un conjunto de pruebas utilizando el archivo testng.xml, se crear\u00e1 el archivo testng-failed.xml en la carpeta test-output despu\u00e9s de que se ejecute la prueba. Despu\u00e9s, podemos ejecutar este archivo igual que el archivo testng.xml. Como este archivo s\u00f3lo almacena las pruebas fallidas, al ejecutarlo s\u00f3lo se ejecutar\u00e1n las pruebas fallidas.<\/p>\n\n
A veces, en el informe de ejecuci\u00f3n de la prueba aparecen fallos que no est\u00e1n causados por problemas en la aplicaci\u00f3n. La causa de estos problemas puede estar relacionada con la configuraci\u00f3n del entorno de prueba o con alg\u00fan problema ocasional del servidor. Para asegurarnos de que los fallos notificados en el informe de prueba son reales y no s\u00f3lo casos aislados, podemos volver a ejecutar los casos de prueba fallidos para eliminar los resultados de prueba falsos negativos en los informes de prueba.<\/p>\n\n
Para reintentar autom\u00e1ticamente los casos de prueba fallidos durante la ejecuci\u00f3n real de la prueba, necesitamos implementar la interfaz IRetryAnalyzer proporcionada por TestNG. La interfaz IRetryAnalyzer proporciona m\u00e9todos para controlar la repetici\u00f3n de las pruebas. Aqu\u00ed anularemos el m\u00e9todo retry() de IRetryAnalyzer para asegurarnos de que la prueba se ejecuta en caso de fallo con el l\u00edmite de reintentos especificado. Gracias a los comentarios del fragmento, es comprensible.<\/p>\n\n
package com.artoftesting.test;\n\nimport org.testng.IRetryAnalyzer;\n\nimport org.testng.ITestResult;\n\npublic class RetryAnalyzer implements IRetryAnalyzer {\n\n\u00a0\/\/Counter to keep track of retry attempts\n\n\u00a0int retryAttemptsCounter = 0;\n\n\u00a0\/\/The max limit to retry running of failed test cases\n\n\u00a0\/\/Set the value to the number of times we want to retry\n\n\u00a0int maxRetryLimit = 1;\n\n\u00a0\/\/Method to attempt retries for failure tests\n\n\u00a0public boolean retry(ITestResult result) {\n\n\u00a0if (!result.isSuccess()) {\n\n\u00a0if(retryAttemptsCounter < maxRetryLimit){\n\n\u00a0retryAttemptsCounter++;\n\n\u00a0return true;\n\n\u00a0}\n\n\u00a0}\n\n\u00a0return false;\n\n\u00a0}\u00a0\n\n}<\/code><\/pre>\n\nEn el ejemplo, crearemos un m\u00e9todo de prueba ficticio y lo haremos fallar intencionadamente mediante el m\u00e9todo assert.fail(). Aqu\u00ed establecemos el atributo retryAnalyzer de la anotaci\u00f3n @Test utilizando la clase RetryAnalyzer.class que creamos anteriormente.<\/p>\n\n
@Test(retryAnalyzer = RetryAnalyzer.class)\n\n\u00a0\u00a0\u00a0\u00a0public void intentionallyFailingTest(){\n\n\u00a0\u00a0\u00a0\u00a0\u00a0System.out.println(\"Executing Test\");\n\n\u00a0\u00a0\u00a0\u00a0\u00a0Assert.fail(\"Failing Test\");\n\n\u00a0\u00a0\u00a0\u00a0}<\/code><\/pre>\n\nResultado de la prueba<\/h2>\n\n
===============================================<\/strong><\/p>\n\nConjunto de pruebas<\/strong><\/p>\n\nTotal de pruebas realizadas: 2, Fallos: 1, Omisiones: 1<\/strong><\/p>\n\n===============================================<\/strong><\/p>\n\nAqu\u00ed podemos observar que el n\u00famero de ejecuciones del m\u00e9todo es de 2 con un fallo y un salto. La primera vez que falle el m\u00e9todo de prueba, se marcar\u00e1 como omitido y, a continuaci\u00f3n, la prueba volver\u00e1 a ejecutarse gracias a la l\u00f3gica proporcionada en RetryAnalyzer.<\/p>\n\n
Ahora s\u00f3lo hay un problema, necesitamos establecer el atributo retryAnalyzer en cada anotaci\u00f3n @Test. Para solucionarlo, podemos implementar la interfaz IAnnotationTransformer. Esta interfaz permite cambiar la anotaci\u00f3n testNG sobre la marcha. As\u00ed que creamos una clase que implemente la interfaz IAnnotationTransformer y hacemos que establezca RetryAnalyzer para las anotaciones @Test.<\/p>\n\n
package com.ittester.test;\n\nimport java.lang.reflect.Constructor;\n\nimport java.lang.reflect.Method;\n\nimport org.testng.IAnnotationTransformer;\n\nimport org.testng.IRetryAnalyzer;\n\nimport org.testng.annotations.ITestAnnotation;\n\npublic class FailureRetryListener implements IAnnotationTransformer {\n\n\u00a0\/\/Overriding the transform method to set the RetryAnalyzer\n\n\u00a0public void transform(ITestAnnotation testAnnotation, Class testClass,\u00a0\n\n\u00a0Constructor testConstructor, Method testMethod) {\n\n\u00a0IRetryAnalyzer retry = testAnnotation.getRetryAnalyzer();\n\n\u00a0if (retry == null)\n\n\u00a0testAnnotation.setRetryAnalyzer(RetryAnalyzer.class);\n\n\u00a0}\n\n}<\/code><\/pre>\n\nDespu\u00e9s de crear el listener, podemos especificarlo en el archivo testNG.xml de la siguiente manera-<\/p>\n\n
<listeners>\n\n\u00a0\u00a0\u00a0<listener class-name=\"com.ittester.test.FailureRetryListener\"\/>\n\n<\/listeners><\/code><\/pre>\n\nAhora no tenemos que establecer retryAnalyzer en cada anotaci\u00f3n @Test. Si tenemos un oyente especificado en el archivo testng.xml, funcionar\u00e1 para todas las pruebas.<\/p>\n\n
PD: Si quieres a\u00f1adir la funcionalidad de reintento s\u00f3lo a un conjunto limitado de m\u00e9todos de prueba, entonces basta con establecer la anotaci\u00f3n @Test con el atributo retryAnalyzer utilizando RetryAnalyzer.class, no es necesario implementar IAnnotationTransformer y a\u00f1adir un oyente en el archivo testng.xml.<\/p>\n","protected":false},"excerpt":{"rendered":"
En este art\u00edculo, aprenderemos a reintentar casos de prueba fallidos utilizando TestNG. Examinamos dos enfoques para conseguirlo.<\/p>\n","protected":false},"author":8,"featured_media":1820,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[36],"tags":[],"class_list":["post-1819","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-tutorial-testng"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/posts\/1819","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/users\/8"}],"replies":[{"embeddable":true,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/comments?post=1819"}],"version-history":[{"count":2,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/posts\/1819\/revisions"}],"predecessor-version":[{"id":2246,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/posts\/1819\/revisions\/2246"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/media\/1820"}],"wp:attachment":[{"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/media?parent=1819"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/categories?post=1819"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/tags?post=1819"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}