Testes de Interface Web

Eu comecei a mexer com a ferramenta Selenium em 2006. Deixei de usar as ferramentas de teste de interface Web mais populares da época (HTMLUnit e JWebUnit) porque elas não permitiam buscar elementos na página por XPath ou DOM, que pode ser muito útil para testar interfaces mal organizadas (com baixa testabilidade). Até na época havia implementado uma IDE em Java/Swing para criação dos testes, isso porque a Selenium-IDE também estava no começo. Bom, valeu um pouco, já que a Selenium-IDE adotou alguns detalhezinhos bobos da minha ferramenta.

Desde de então, o Selenium acabou se tornando a ferramenta mais popular. O fato de que os testes com Selenium são executados no mesmo navegador do usuário final é um bom argumento para utilizá-la. Agora, todo mundo que já usou Selenium se deparou com os mesmos problemas: Lentidão dos testes e Testes intermitentes (principalmente quem usa só o Selenium-IDE em interfaces muito dinâmicas). Por causa do desempenho dos testes, surgiu a Selenium-Grid. Já para testes intermitentes, Selenium-RC.

Mais recentemente, surgiu a ferramenta Webdriver, que usa as APIs reais do navegador ao invés de uma API simulada por Javascript, que é o caso do Selenium. Além de tornar os testes ainda mais reais, eles também ficam mais rápidos. A ferramenta Webdriver está se integrando com a Selenium e virando a Selenium 2.

Não o bastante, a ferramenta ainda fornece uma API comum e abstrata para várias ferramentas de testes (Selenium, HTMLUnit...). Isso é MUITO legal porque com a mudança de uma linha, ou de um arquivo de configuração, você utiliza o mesmo código de testes para fazer testes com diferentes ferramentas, principalmente porque a HTMLUnit também evoluiu.

A HTMLUnit não é um framework de testes, é um navegador de testes implementado em Java. Ele possui uma estrutura interna de um navegador, mas não possui a camada de renderização do HTML, ou seja, não é possível visualizar a interface. Justamente porque ele não renderiza a interface, a velocidade dos testes é muito mais rápida do que se utilizar o Webdriver ou Selenium.

Eu fui usar o HTMLUnit apenas em 2009, e só então que eu vi como minha produtividade aumentou em relação aos testes com Selenium. Como o próprio nome da ferramenta sugere, os testes ficam parecidos com testes de unidade.

O que XP ou o próprio Martin Fowler fala, é que os testes de aceitação, ou essas baterias lentas de testes devem ser executadas apenas em um ambiente de integração contínua, para não atrasar o desenvolvimento. Durante a implementação, compensa executar apenas os casos de testes diretamente ligados ao módulo que está sendo trabalhado.

Contudo, por causa do desempenho do HTMLUnit, pode até ser viável executar toda a bateria de testes durante o desenvolvimento, assim como ocorre com os testes de unidade (sem falar das otimizações, estilo as que o JUnitMax faz). O desempenho depende especialmente da quantidade de testes. Cada projeto pode experimentar executar os testes durante a implementação e observar se a produtividade está sendo melhorada ou prejudicada.

Concluindo, pode compensar utilizar o Webdriver com HTMLUnit durante o desenvolvimento, e Webdriver com Selenium ou "puro" em ambiente de integração contínua.


Resumo:

• Evite usar o Selenium.
• Use o Webdriver (Selenium 2)
• Use o HTMLUnit com Webdriver durante o desenvolvimento
• Use o Webdriver "puro" em ambiente de integração contínua

Fontes:

http://htmlunit.sourceforge.net/
http://seleniumhq.org/docs/09_webdriver.html
http://seleniumhq.org/
http://seleniumhq.org/projects/ide/
http://seleniumhq.org/projects/remote-control/
http://selenium-grid.seleniumhq.org/