logo

Teste as Funcionalidades e não o Texto.

Existe 2 problemas que todos enfrentam quando começam a automatizar testes funcionais de interface. O primeiro deles é testar tudo (e claro que eles costumam falhar miseravelmente e a frustração é grande que eles desistem). Os que continuam em sua jornada de automação cometem o segundo grande erro que é fazer validação de texto.

Mas porquê validar texto é um grande erro?

É um pouco difícil para iniciantes vincular que quando a automação dele quebra, geralmente é um a mudança de texto. Outro fator que gera retrabalho de automação é a localização do objeto mas é assunto para outro post.

Quando seu script automatizado quebra, você olha primeiro a evidência de erro. Depois vem o teste manual para ter certeza que está funcionando e depois vem o debug.

Po! Não está clicando no botão "enviar"!

%!ˆ%@!! Não está achando o texto de informação mas está ali na evidência!

Depois de bater a cabeça no teclado durante alguns minutos, horas, ?dias?, você descobre que tem um espaço a mais no texto, que foi colocado letra maiúscula na primeira letra, etc..

A medida que a vida de automatizador vai te calejando, você vai perdendo menos tempo com isso, mas uma hora ou outra você vai estar viciado com seu código e aplicação e coisas bestas vão passar despercebidas.

E como resolver isso?!

É bem simples. Primeiro você precisa entender que:

Exemplo 1:

Esta é uma imagem randômica da internet de um formulário de contato.

Your message was sucessfully sent.

Imagina que amanhã, seu gerente ou P.O quer que tenha uma exclamação ali e ninguém te avisa que vai mudar. Se você procurar pela frase dentro de alguma div ou xpath genérico, seu teste vai quebrar.

Your message was sucessfully sent!

Digamos que sua aplicação siga os preceitos básicos de interface web que é utilizar classes css para estilizar determinados tipos de mensagem.

<div id="msg">  
    <span class="msg-sucess">
        Your message was sucessfully sent.
    </span>
</div>  

Ao invês de qualquer outra maneira e validar a mensagem de sucesso, por que não validar que a funcionalidade de enviar um formulário é precedida de uma mensagem de sucesso, seja ela qual for?

Simplificando:

//ruby + capybara
page.has_selector?(:css, "span.msg-sucess")  

Eu estou validando que a pagina está exibindo uma mensagem de sucesso, pois a classe msg-sucess está ligada diretamente a funcionalidade.
Por trás do pano, deve ter um javascript que manipula o atributo display:none para display:block

Exemplo 2

Você esta automatizando o acesso ao menu da sua aplicação, que usa um icon junto com texto:

Esse é o melhor dos mundos, no restante geralmente o DIV ou o SPAN que contem o link geralmente tem um ID que é referente a esse link.

Voltando ao exemplo, teríamos um código +- assim:

<div class="toggle-menu>  
       <div class="menu-drop-down">
           <ul>
               <li>
                   <a href="link">
                       <i class="fa fa-download"></i>
                       Downloads
                </a>
            </li>
            ...
        </ul>
    </div>
</div>  

Neste caso, poderíamos fazer o link para o ícone, pois sabemos que ele remete a página de download:

//ruby+capybara
page.find(:css, "i.fa.fa-download").click  

Poderia ter outras referências que não mudam para evitar que você amarre seus scripts com texto pleno.

O buraco é mais embaixo

Você pode até estar falando:

Bah! Eu nunca vou ter um problema desses

Agora imagina se você trabalha em uma empresa internacional, que tem 3 idiomas + N produtos e a junção produto + pais pode ser != do da tradução normal da lingua.

exemplo:

Imagina você ficar fazendo tracking disso no seu código?!
Acho melhor não né :)

Se você tiver mais dicas sobre como evitar amarrar seu teste com texto, compartilhe nos comentários ou faça um post de resposta :)


Sobre o Autor: Leonardo Galani é Agile Tester, dev, gamer, dj and etc. Mantém o fórum http://agiletesters.com.br | http://leonardobg.com.br (profile)| http://lazytester.com (blog em inglês)
http://br.linkedin.com/in/leonardogalani/

comments powered by Disqus