Teste as Funcionalidades e não o Texto.
5 January 2015 / ruby
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:
Seu código não precisa testar tudo
Seu código não pode ter referências mutáveis
Seu código deve testar funcionalidades e não texto ( a não ser que o texto seja data driven e seja cenários distintos das suas funcionalidades..)
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.
Digamos que sua aplicação siga os preceitos básicos de interface web que é utilizar classes css para estilizar determinados tipos de mensagem.
<span class="msg-sucess">
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?
//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
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">
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.
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.
O ícone de log-off do produto X para o pais Colômbia, o P.O quer tenha o nome em inglês... OK
O mesmo ícone para produto X para o México, vem com o texto "salir"
O mesmo ícone para o produto X para argentina se chama "adios"
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 :)
— leonardo.galani —
Tornando-se um QA DevOps em 7 passos.
Estava nos meus rascunhos um arquivo sobre o caminho das pedras para se tornar um devops; mas aí surgiu a oportunidade de falar sobre testers técnicos no TDC2014, e eu acabei criando a