Estou navegando no stackoverflow há alguns dias, tentando descobrir como executar novamente uma classe de teste inteira, e não apenas uma @Test
etapa. Muitos dizem que isso não é suportado pelo TestNG e IRetryAnalyzer
, embora alguns tenham postado soluções alternativas, isso realmente não funciona. Alguém conseguiu fazer isso? E apenas para esclarecer as razões para isso, a fim de evitar respostas que digam que não são suportadas de propósito: TestNG é uma ferramenta não apenas para desenvolvedores. O que também é usado nos testadores sw para o e2e. Os testes E2e podem ter etapas que dependem cada uma das anteriores. Portanto, sim, é válido executar novamente toda a classe de teste, em vez de simples @Test
, o que pode ser feito facilmente via IRetryAnalyzer
.
Um exemplo do que eu quero alcançar seria:
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
falha, eu quero executar novamente class DemoTest
e não apenastestStep_2
fonte
Respostas:
Ok, eu sei que você provavelmente deseja uma propriedade fácil que possa ser especificada na sua @BeforeClass ou algo parecido, mas talvez seja necessário aguardar a implementação. Pelo menos eu também não consegui encontrar.
A seguir, é feio como o inferno, mas acho que faz o trabalho, pelo menos em pequena escala, resta ver como ele se comporta em cenários mais complexos. Talvez com mais tempo, isso possa ser aprimorado para algo melhor.
Ok, então eu criei uma classe de teste semelhante à sua:
Eu tenho a
Listener
classe super apenas no caso em que gostaria de estender isso para outras classes, mas você também pode definir o ouvinte em sua classe de teste.Três dos 4 métodos acima têm a
RetryAnalyzer
. Deixei otestStep_4
sem para ter certeza de que o que estou fazendo a seguir não mexa com o resto da execução. DitoRetryAnalyzer
, na verdade, não tentará novamente (observe que o método retornaráfalse
), mas fará o seguinte:Isso criará uma execução dentro da sua execução. Não mexerá no relatório e, assim que terminar, continuará com sua execução principal. Mas ele "tentará" novamente os métodos dentro desse grupo.
Sim, eu sei, eu sei. Isso significa que você executará seu conjunto de testes para sempre em um loop eterno. É por isso que o
RetryAnnotationTransformer
. Nele, removeremos o RetryAnalyzer da segunda execução desses testes:Agora temos o último dos nossos problemas. Nosso conjunto de testes original não sabe nada sobre a "repetição" de execução lá. É aqui que fica realmente feio. Precisamos contar ao nosso repórter o que aconteceu. E esta é a parte que eu encorajo você a melhorar. Falta-me tempo para fazer algo melhor, mas, se puder, vou editá-lo em algum momento.
Primeiro, precisamos saber se a execução retryTestNG foi bem-sucedida. Provavelmente existem milhões de maneiras de fazer isso melhor, mas por enquanto isso funciona. Eu configurei um ouvinte apenas para a nova tentativa de execução. Você pode vê-lo
TestRetry
acima e consiste no seguinte:Agora, o Ouvinte da suíte principal, o que você viu acima na superclasse
TestConfig
verá se a execução aconteceu e se correu bem e atualizará o relatório:O relatório deve mostrar agora três testes aprovados (à medida que foram repetidos) e um que falhou porque não fazia parte dos outros três testes:
Sei que não é o que você está procurando, mas ajudo a atendê-lo até que eles adicionem a funcionalidade ao TestNG.
fonte