Testes automatizados de interface

Hoje vou falar sobre testes automatizados de interface, focando
principalmente na ferramenta Selenium.

Fazer testes é uma cultura que já está bem desenvolvida pelo lado
de programação server-side, mas que ainda é pouco desenvolvido por
programadores client-side, aliás, muitos desenvolvedores client-side
nem sequer sabem da existência de ferramentas para tal, ou acham que
não tem tanta importância assim.

Testar interface tem um foco bem diferente de testar classes em Java
por exemplo, já que trabalhamos com elementos e interações de
usuários na página, mas tem tanto valor agregado quanto teste
server-side.

Vale lembrar que esse tipo de testes é bem mais flexível e seu
resultado vai depender do nível de detalhamento aplicado aos testes.

Vou falar especificamente de uma ferramenta chamada Selenium, que é
uma ferramenta que vem crescendo nos últimos tempos que faz esse
tipo de teste. Ela aparece em três formas: Selenium IDE, Selenium RC
e Selenium Grid. A IDE é um plugin para o navegador Firefox, bem
prático e leve, com ele podemos criar e editar testes de forma bem
simples. O RC serve para rodar um grupo de testes de forma
automática, e em navegadores diferentes de Firefox, por exemplo
podemos rodá-los no Safari, podendo ser usada com linguagens de
programação como Java, PHP, Python, etc, podendo também ser rodada
em navegadores distintos (sabemos que alguns navegadores se comportam
de forma diferente com mesmas regras), e por último vem o Grid, que
serve para paralelizar os testes, é bom para quando temos uma massa
grande de testes e, quando rodada de forma linear, consome muito tempo
para o término.

A abordagem de hoje vai ser um pouco mais teórica, mas vou continuar
no próximo artigo com a parte prática.

Os motivos para automatizar são muitos. Podemos citar alguns como:

1. Alguém vai criar uma funcionalidade nova em alguma parte da
   página, como muitas coisas de Javascript podem ser reaproveitadas,
   sobrescritas ou modificadas por causa da nova funcionalidade, alguma
   coisa pode ter parado de funcionar. Se o sistema já estivesse com os
   testes feitos, bastaria rodar todos eles após o desenvolvimento da
   nova funcionalidade e, caso passasse nos testes, então essa alteração
   não teria afetado em nada, caso contrário, bastaria ver onde o teste parou e
   analisar o erro.
2. A equipe quer atualizar a versão de biblioteca de Javascript
   para a mais atual, caso não tivesse feito os testes, a equipe de
   testes de qualidade teria muito trabalho a fazer e a entrega do
   projeto poderia ser atrasada por conta disso.
3. Fazer testes com ações reais de usuários, pois essa
   ferramenta faz uma simulação exata de ações feitas por usuários,
   como clicks e preenchimento de formulários
4. Agilizar os testes, pois eles são feitos de forma bem rápida
   (a menos que o testador queira diminuir a velocidade, o que também
   e possível)
5. Simplicidade, já que pela forma como são criados, qualquer
   pessoa da equipe consegue adicionar ou modificar algo neles a
   qualquer momento.

Enfim, existem diversos outros motivos, mas esses já descrevem bem a
ferramenta e seu uso. Logicamente que a forma como eles são feitos
influencia bastante tanto no bom resultado como também na agilidade
de sua execução, já que é bem flexível e permite ao criador
criá-lo de forma simples ou complexa, bem como de forma errada e
certa.

Para criar um teste no selenium, a forma mais fácil seria abrir a
IDE do selenium e apertar um botão de record, para começar a
gravar, depois disso começar a navegar pelo site como um usuário
comum e no final parar a gravação. Simples assim. Esse teste
poderia ser bem útil para definir que esses links que foram clicados
nunca fossem desabilitados em algum momento. Mas ele não testa
coisas mais avançadas e que podem ser feitas com a ferramenta.

Testes mais complexos podem fazer o mesmo fluxo, mas com
interferências entre passos da navegação para validar ocorrências
ou não ocorrências de valores em determinado elemento. Para
selecionar esses elementos, podemos fazer referência direta a
elementos de ids, ou names, como também fazer buscas mais dinâmicas
por Javascript ou até mesmo xpath. Nessas interferências podemos
também gravar coisas em cookie para validar páginas que estão à
frente no fluxo de navegação.

Com a ferramenta podemos testar literalmente todos os elementos
presentes na árvore DOM do sistema, ou seja, podemos até mesmo
validar elementos ocultos como elementos de input do tipo hidden, ou
objetos sem visibilidades via CSS. Vai da criatividade do testador o
limite de até o que podemos ou não testar sobre a interface.

No geral os testes são tão bons quanto a capacidade do testador em
se passar por um usuário final na hora da criação dos testes.

No início, essas tarefas podem parecer complicadas e os testes
gerados podem parecer que não são tão úteis, mas não é verdade,
pois as páginas podem crescer e aumentar o fluxo de navegação, e o
teste que parece inútil poderá livrar bastante tempo de testes no
futuro.

Outra coisa importante é implantar a cultura de testes para a equipe
inteira, pois isso melhora o nível dos testes gerados, já que mais
pessoas e com mais visões vão e agilizam bastante o projeto.

Para ver o projeto por completo temos o site: http://seleniumhq.org/