Testes de Aceitação em Aplicações Swing

E aí,­ galera! Tudo bem com vocês? Meu nome é Daniel Martins, administrador do blog batteries not included. Fui gentilmente convidado pelo Rafael, administrador deste blog, para publicar sobre um assunto de minha escolha. Foi difí­cil escolher, mas espero que o texto seja de interesse de todos!

Introdução

Levando em consideração que este blog disponibiliza muito material interessante sobre desenvolvimento com Swing, eu acabei optando por não sair muito desse assunto. Decidi escrever sobre um tema que é, ao mesmo tempo, muito importante e pouco comentado pelos desenvolvedores: testes de aceitação em aplicações Swing. É através dos testes de aceitação que podemos simular a utilização do sistema por um usuário e verificar se as reações do sistema correspondem ao esperado.

Acredito que a falta de informação sobre o assunto se deve a uma questão meramente cultural, pois costumamos associar esse tipo de tarefa com trabalho manual, o que era verdade há alguns anos atrás. Entretanto, com o advento das metodologias ágeis, a cada dia surgem novas ferramentas capazes de nos ajudar a automatizar esse processo.

Tipos de Ferramentas

Antes de partir para a apresentação das ferramentas, precisamos aprender um pouco sobre como elas são agrupadas. Basicamente, existem dois tipos de ferramentas para criação e execução de testes de aceitação: as do tipo rec-and-play e as programáveis:

• As ferramentas rec-and-play são ferramentas que gravam as ações do usuário com o sistema, permitindo que as mesmas ações sejam reproduzidas de uma forma automatizada;
• Já o segundo grupo compreende as ferramentas que fornecem uma API para que o desenvolvedor possa simular as interações do usuário com o sistema.

Optar pela utilização de uma ferramenta de um grupo ou de outro pode impactar positiva ou negativamente no seu projeto. Embora cada ferramenta tenha suas próprias caracterí­sticas, podemos indicar algumas vantagens e desvantagens que costumam se aplicar às ferramentas de cada um desses grupos.

Em relação às ferramentas do tipo rec-and-play, a principal vantagem é que não é necessário saber programar para ser capaz de criar e reproduzir os testes. Isso torna qualquer pessoa apta a fazer este trabalho. Além disso, o fato de não se precisar programar os testes torna todo esse processo mais ágil.

Entretanto, a grande desvantagem de ferramentas desse grupo é que os testes se tornam extremamente sensí­veis a qualquer modificação na view. Por exemplo, se um determinado teste clica com o mouse em um botão que ficava na posição x da view, e que agora está na posição y, o teste falhará e deverá ser modificado para se adaptar à "nova" view.

Já as ferramentas que estão no segundo grupo são mais confiáveis neste aspecto, sendo necessário modificar os testes apenas em casos mais extremos, como na troca de um componente por outro. A desvantagem é que as ferramentas deste grupo demandam mais esforço na criação dos testes.

Eu particularmente não simpatizo com as ferramentas rec-and-play, pois os testes costumam "quebrar" com muito mais facilidade. Mas devo lembrar que "cada caso é um caso" e a melhor atitude é ponderar os prós e contras de cada tipo de ferramenta antes de fazer sua escolha.

Ferramentas Disponíveis

Agora que já sabemos diferenciar os tipos de ferramentas, nos resta agora conhecer algumas das opções disponí­veis:

• Jemmy - O Jemmy é uma biblioteca para testes de interfaces gráficas Swing e AWT desenvolvido pelo time do NetBeans. Trata-se de uma ferramenta onde os testes são criados e executados programaticamente, através de uma API bem definida. A documentação ainda é fraca, mas o site está repleto de exemplos de testes, o que já é de grande ajuda.
• UISpec4J - Feito em cima do JUnit e pode ser usado para testar interfaces gráficas baseadas em Swing de forma programática. A API fornecida por esta ferramenta é mais simples e intuitiva que a fornecida pelo Jemmy. A má notí­cia é que, apesar de já estar disponí­vel a algum tempo (desde meados de 2004), existem componentes Swing que não são 100% suportados. Além disso, a ferramenta não é multi-plataforma "de verdade" (alguns testes que fiz não funcionaram no Linux). Em relação a documentação, ela é fraca, mas é possí­vel se virar bem só com os JavaDocs.
• Marathon - Esta ferramenta é do tipo rec-and-play e os testes gravados são "convertidos" em scripts Jython, facilitando a modificação dos testes sem que seja necessário recriá-los. Uma coisa legal é que podemos testar qualquer tipo de componente sem que seja necessário trabalho extra (diferentemente do que acontece com o Jemmy e o UISpec4J, por exemplo). A documentação é razoável e dá para se virar sem nenhum problema.
• JFCUnit - É uma ferramenta para criação programática de testes de interfaces gráficas Swing, feita como uma extensão ao JUnit. Tudo indica que este é um projeto abandonado, já que o último release foi feito no dia 21 de Dezembro de 2004.
• Abbot - O Abbot é uma extensão do JUnit para testes de interfaces gráficas semelhante ao JFCUnit. A diferença é que o projeto não parece estar abandonado.
• TestNG-Abbot - O TestNG-Abbot é um projeto cujo objetivo é adaptar o Abbot para rodar sobre o TestNG. A documentação é praticamente inexistente, sendo que as únicas referências que encontrei foram posts em blogs e um artigo no developerworks.com.

É óbvio que existem outras ferramentas além das citadas, inclusive ferramentas pagas. Para mais detalhes, visite esta página.

Mas qual ferramenta escolher?

A função deste artigo não é oferecer um review detalhado sobre cada uma das alternativas, mas sim mostrar quais são essas alternativas. Portanto, a tarefa de descobrir qual ferramenta melhor se adapta às suas necessidades é sua. Minha dica é: crie uma aplicação bem simples nos moldes das que você costuma desenvolver e verifique quais ferramentas fornecem os recursos necessários para testá-la adequadamente.

Em alguns dias, eu publicarei no meu blog um pouco mais sobre o Jemmy. Será mostrado, na prática, como utilizá-lo para testar uma aplicação Swing para conversão de temperaturas.

Bom... eu vou ficando por aqui. Gostaria de agradecer novamente ao Rafael por me oferecer a oportunidade de escrever aqui. Valeu mesmo!

Um abração a todos e bons testes!