He estado buscando stackoverflow durante algunos días, tratando de encontrar cómo volver a ejecutar una clase de prueba completa, y no solo un @Test
paso. Muchos dicen que esto no es compatible con TestNG y IRetryAnalyzer
, mientras que algunos han publicado soluciones alternativas, eso realmente no funciona. ¿Alguien ha logrado hacerlo? Y solo para aclarar las razones de esto, con el fin de evitar respuestas que dicen que no es compatible con el propósito: TestNG es una herramienta no solo para desarrolladores. Lo que significa que también se utiliza desde probadores de sw para pruebas e2e. Las pruebas E2e pueden tener pasos que dependen cada uno del anterior. Entonces sí, es válido volver a ejecutar toda la clase de prueba, en lugar de simple @Test
, lo cual se puede hacer fácilmente a través de IRetryAnalyzer
.
Un ejemplo de lo que quiero lograr sería:
public class DemoTest extends TestBase {
@Test(alwaysRun = true, description = "Do this")
public void testStep_1() {
driver.navigate().to("http://www.stackoverflow.com");
Assert.assertEquals(driver.getCurrentUrl().contains("stackoverflow)"));
}
@Test(alwaysRun = true, dependsOnMethods = "testStep_1", description = "Do that")
public void testStep_2() {
driver.press("button");
Assert.assertEquals(true, driver.elementIsVisible("button"));
}
@Test(alwaysRun = true, dependsOnMethods = "testStep_2", description = "Do something else")
public void testStep_3() {
driver.press("button2");
Assert.assertEquals(true, driver.elementIsVisible("button"));
}
}
Digamos que testStep_2
falla, quiero volver a ejecutar class DemoTest
y no solotestStep_2
fuente
Respuestas:
Bien, sé que probablemente quieras una propiedad fácil que puedas especificar en tu @BeforeClass o algo así, pero es posible que debamos esperar a que se implemente. Al menos tampoco pude encontrarlo.
Lo siguiente es feo como el infierno, pero creo que hace el trabajo, al menos en pequeña escala, se deja ver cómo se comporta en escenarios más complejos. Quizás con más tiempo, esto se puede mejorar en algo mejor.
Bien, entonces creé una clase de prueba similar a la tuya:
Tengo el
Listener
en la súper clase solo en el caso de que me gustaría extender esto a otras clases, pero también puede configurar el oyente en su clase de prueba.Tres de los 4 métodos anteriores tienen a
RetryAnalyzer
. Lo dejétestStep_4
sin él para asegurarme de que lo que estoy haciendo a continuación no interfiera con el resto de la ejecución. DichoRetryAnalyzer
no volverá a intentarlo (tenga en cuenta que el método regresafalse
), pero hará lo siguiente:Esto creará una ejecución dentro de su ejecución. No interferirá con el informe, y tan pronto como termine, continuará con su ejecución principal. Pero "reintentará" los métodos dentro de ese grupo.
Sí, lo sé, lo sé. Esto significa que ejecutará su conjunto de pruebas para siempre en un bucle eterno. Por eso el
RetryAnnotationTransformer
. En él, eliminaremos el RetryAnalyzer de la segunda ejecución de esas pruebas:Ahora tenemos el último de nuestros problemas. Nuestro conjunto de pruebas original no sabe nada sobre esa ejecución de "reintento" allí. Aquí es donde se pone realmente feo. Necesitamos decirle a nuestro reportero lo que acaba de suceder. Y esta es la parte que te animo a mejorar. Me falta el tiempo para hacer algo mejor, pero si puedo, lo editaré en algún momento.
Primero, necesitamos saber si la ejecución de retryTestNG fue exitosa. Probablemente hay un millón de formas de hacerlo mejor, pero por ahora esto funciona. Configuré un oyente solo para volver a intentar la ejecución. Puede verlo
TestRetry
arriba y consta de lo siguiente:Ahora el oyente de la suite principal, el que viste arriba en la superclase
TestConfig
verá si sucedió la ejecución y si salió bien y actualizará el informe:El informe debe mostrar ahora 3 pruebas aprobadas (como fueron reintentadas) y una que falló porque no era parte de las otras 3 pruebas:
Sé que no es lo que estás buscando, pero te ayudo a que te sirva hasta que agreguen la funcionalidad a TestNG.
fuente