Smallthoughts

Após alguns anos nesta indústria, e se você, como eu, é fã de técnicas ágeis de desenvolvimento de software e viciado em testes (testes, testes, testes!!!), acaba colecionando uma série de ferramentas, bibliotecas e idiomas para facilitar o seu trabalho. Reuni aqui aquelas que uso com frequência e aquelas que lembro ter usado por alguma razão em particular, que estão no meu cinto de utilidades:

1. JUnit: Comecei com o óbvio, o pai de todos. A não ser que você tenha se escondido num bunker anti-nuclear pelos últimos anos, você já ouviu falar, ou já usou testes unitários. Se você for mesmo sortudo, pode até mesmo ter praticado Test Driven Development. Aliás, uma boa referência no assunto é Test Driven Development: By Example.
2. Refatoramento: Ok, ok, já vou parar com as obviedades, mas não dá para falar em desenvolvimento ágil sem uma boa IDE que permita refatoramento. Tanto o IDE Eclipse quanto o NetBeans, meus favoritos, fornecem excelente suporte. Acho que é pouco difundido e que está caindo no esquecimento o fato de que não só os refatoramentos fornecidos pela sua IDE são os que existem, e que o livro que popularizou estas técnicas foi o Refactoring: Improving the Design of Existing Code. Nele existem uns tantos outros que não são implementados por nenhuma IDE, muitas vezes por não permitir a automação da tarefa. Vale a pena uma olhada atenta.
3. Maven: O gerenciamento de builds pode ser um assunto complexo e fadado a erros se não for bem administrado, e no final das contas a entrega para o cliente do produto é um momento crucial, o ápice de meses de desenvolvimento com suas melhores ferramentas e técnicas, e você quer dar a impressão certa. Para mim, o maven é a ferramenta de gerenciamento de builds da minha escolha, me livra de uma série de problemas dos quais não quero saber detalhes, e me fornece uma série de relatórios sobre a saúde do projeto, como relatório de cobertura de testes, aderência a convenção de formatação do código, Javadoc, etc..., todos reunidos num belíssimo site do projeto. Ótimo para impressionar seu gerente.
4. EasyMock: Idealmente o teste unitário tem que ter um tempo de execução muito curto, uns poucos milissegundos. Se você começa a envolver bancos de dados, serviços da plataforma JEE, I/O em geral, o ciclo de realimentação programa-refatora-testa passa a ser muito lento, e o programador pára de testar como resultado natural. Os testes unitários devem permitir que sejam executados dezenas de vezes por dia.  É aí que entra o EasyMock, que permite que vc substitua partes do seu sistema por objetos falsos, com a mesma interface do objeto real, e verificar que o sistema está fazendo as chamadas esperadas. Mágico!
5. DBUnit: E como popular as tabelas que serão usadas no teste com sua massa de teste? Esta é uma tarefa para o DBUnit, que permite inserir e remover dados em tabelas durante seu ciclo de testes.
6. HTTPUnit: o HTTPUnit foi primeiramente pensado para permitir o teste unitário de aplicações web. Com ele você pode acessar uma url, preencher campos em formulários, enviar, verificar a resposta, enfim, emular um usuário humano. Recentemente andei dando uma outra utilidade para ele, acesssando serviços Rest e verificando os dados da resposta. Muito bom.
7. Liquibase: Sou fã deste projeto. Ao brincar com Ruby on Rails, fiquei realmente maravilhado com o esquema de gerenciamento de alterações do banco de dados. Ele o faz através de pequenos scripts que fazem parte do próprio projeto, mantendo controle inclusive da versão instalada e executando somente o necessário a cada nova atualização. Ao procurar no mundo Java algo semelhante, me deparei com esta biblioteca e tenho utilizado-a em minhas aplicações com sucesso. Você constrói arquivos XML com as alterações em banco, identificados com o autor e a versão, e a biblioteca toma conta de atualizar o banco de dados aplicando somente a diferença entre versões. Ou então pode-se também apenas, no final de uma iteração, gerar um arquivo com o script a ser executado, em ambiente que exigem maior controle por parte de um DBA. Recomendo.
8. Mercurial: Sou usuário de longa data de CVS e Subversion. Mas sistemas de controle de versão distribuídos estão aí, e dão toda uma nova gama de possibilidades, além de serem extremamente velozes. O Mercurial é utilizado internamente pelo projeto NetBeans, um projeto de grande porte, e muitas das suas operações, como commits, updates, roolbacks, diffs, são praticamente instantâneos. E nada como levar consigo todo o repositório, e fazer commits no site do cliente.
9. P6Spy: Ferramente simples demais, útil demais, estou preocupado em não sofrer atualizações desde 2003. Permite que você monitore a comunicação entre o seu código e o servidor de banco de dados, plugado direto no seu servidor, no teste unitários, em qualquer lugar onde couber um driver JDBC. Excelente para tunning e momentos de total desespero.
10. OpenEJB: Confesso que passei um bom tempo longe da plataforma JEE por traumas com a especificação EJB, preferindo sempre opções que me permitissem agilidade e testes. Nesta época usava bastante o projeto Apache Cactus, mas convenhamos, não é a mesma coisa. O OpenEJB é o contêiner EJB usado pelo servidor Apache Gerônimo, mas pode ser usado em qualquer aplicação JSE, de forma standalone ou junto com o Tomcat, ou ainda nos seus teste unitários, permitindo o teste de mensagens assíncronas JMS, EJBs Stateless, Stateful, Singleton, Time Service, enfim, tudo o que vc espera de um servidor real. Ele ainda toma decisões muito espertinhas para realmente facilitar seu uso em testes unitários, como a criação automática de DataSources, utilizando o banco HSQLDB em memória. Apesar da existência na especificação EJB 3.1 do contêiner embarcado, próprio para uso em aplicações standalone e em teste unitários, a especificação diz que os provedores somente precisam fornecer o perfil EJB Lite, o que, se você precisa como eu testar o restante que não se encontra no perfil, é insuficiente.
11. HSQLDB: E nada melhor para seus testes unitários com banco de dados, do que um banco de dados que permite criar tabelas apenas em memória. É isso, simples assim.
12. SeleniumHQ: Quem já tentou automatizar testes de interfaces com o usuário, sabe que não é uma tarefa fácil. A interface com o usuário é um alvo móvel, difícil de acertar. Eu realmente admiro aqueles que se propõe esta nobre tarefa.  Desenvolver interfaces não é lá a minha praia, mas já brinquei com o Selenium, e fiquei muito impressionado. Tem as mesmas capacidades de ferramentas caras de teste, como a gravação da sua iteração com o sistema, e a capacidade de rodar o mesmo conjunto de testes numa rede de máquinas com diversas configurações de sistemas operacionais e browsers. Com certeza, para a sua próxima killer web app, vale o esforço.
13. Cruise Control: Para saber rapidamente se o código enviado para o repositório continua funcionando, e evitar o pesadelo da fase de integração, nada melhor do que uma ferramenta de integração contínua. Já experimentei o Hudson e o Continuum, mas ainda continuo com o velho e bom Cruise Control. Apesar de ser mais difícil de configurar do que seus irmãos mais novos, permite uma flexibilidade maior na sua configuração, além de ter uma grande estabilidade. Mantenho duas tarefas agendadas: uma build após cada commit de código no repositório, e a construção do site do projeto diariamente.
14. JMeter: E por último, e não menos importante... Não deixe seus testes funcionais para mais tarde por que, senão, pode ser tarde demais. Principalemente testes de desempenho. O JMeter permite que você simule o comportamento de centenas de usuários atacando furiosamente sua aplicação, e encontrar onde aqueles leaks e gargalos estão escondidos.

Longe de ser uma lista definitiva e completa, é a minha lista. E é claro, uma última ferramenta importante é uma pitada de bom senso, afinal de contas, nada de tentar chegar em 100% de cobertura de testes. Pode soar como ideal, mas é sem dúvida, ingênuo. E sempre lembrando as imortais palavras de Dijkstra:

Testing shows the presence, not the absence of bugs.