xi, o teste falhou….

Posted on 22 de julho de 2010 by Leonardo Galani 2 Comments

Imagine o seguinte cenário: Você está testando uma aplicação grande, mas não tão complexa. Para cada teste, existe a premissa que o usuário deverá se logar antes de executar qualquer tipo de teste e deslogar porque cada usuário tem um perfil e uma tela de apresentação diferente. Também ressalto que cada operação deverá ser executada até o final, ou seja, se no meio de uma alteração cadastral você precisar cancelar ou finalizar a operação.

No mundo perfeito, você modulariza seus testes, um para login e outro para logoff, e define seus ‘anotations’ corretamente. (cof.. cof)

<strong>@BeforeSuite</strong>

public void setup() throws Exception 

{

 seleniumServer.start();

 selenium.start();

 }

<strong>@BeforeTest</strong>

public void AntesDeTeste() throws Exception

 {

selenium = comum.Login("usuario", "senha", "selenium")

 } 

<strong>@AfterTest</strong>public void DepoisDoTeste() throws Exception 

{

 selenium = comum.Deslogar("selenium")

 }

 <strong>@AfterSuite

</strong>public void EncerraTeste() throws Exception 

{ 

selenium.stop();

 SeleniumServer.stop();

 }

No mundo perfeito, o Brasil seria campeão eterno da copa do mundo, o nosso presidente saberia ler e escrever, o corinthias perderia todo jogo contra o Atlético-GO (ops..ontem isso foi verdade ) e todos os testes automáticos seriam concluídos sem falha (e mesmo sem bugs, ainda teríamos nossos empregos garantidos rs). #NOT!
Todo analista de teste tem um mantra na hora de escrever / executar testes, sejam eles funcionais ou não funcionais.

“E se….”, “E se….”, “E se….” ” E se eu cadastrar deste jeito?”, “E se eu fazer de outra forma?”

Se você não usa este mantra, você não tem sangue “tester” e merece fogueira (#zueira).
O pessoal que usa Junit sabe usar corretamente TearDownpara tratar caso algum teste de problema (me corrijam se eu estiver falando besteira) porém pelo meu entendimento de TestNG, ele não funciona bem assim.

Como TestNG é o caminho da verdade e da luz, ele disponibiliza a interface ITestResult que é usada para fazer o tracking do resultado dos testes.
Com isso em mente, podemos preparar o teste para receber falhas.

Código:

<strong>@BeforeSuite

</strong>public void setup() throws Exception 

{ 

seleniumServer.start();

 selenium.start();

 }

<strong>@BeforeTest

</strong>public void AntesDeTeste() throws Exception 

{

 selenium = comum.Login("usuario", "senha", "selenium") 

}

// Aqui jaz o pulo do gato 

public void DepoisDoTeste(ITestResult result) throws Exception

 {

 if(!result.iSucess) 

{

 selenium.stop();

 selenium.start(); 

}

else

{

 selenium = comum.Deslogar("selenium") 

}

 }

 <strong>@AfterSuite

</strong>public void EncerraTeste() throws Exception

 {

selenium.stop();

 SeleniumServer.stop();

 }

O que eu fiz foi pegar o resultado booleano do método isSucess da instancia iTestResult e validar se ela veio FALSE para entrar dentro ‘IF’.
Dentro do IF você trata seu erro, como por exemplo, chamar o stop() e start() para ‘matar’ sessão do browser (matando junto cache da aplicação, a não ser que a sessão fique armazenada em cookie, mas ai já é outra história, outro post) e já criar uma sessão limpa para trabalhar.

Existe outro outros 2 métodos de como é possível fazer esse tratamento, mas vou falar posteriormente quando abranger o annotation Java útil @override.
Até.